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ABSTRACT 


A Networked Virtual Environment (Net-VE) is a distributed software system in 
which multiple users interact with each other in real time even though these users may be 
located around the world [Zyda 99]. Net-VEs gained first attention through a variety of 
DOD and Academic research projects. After release of the multiplayer game DOOM, the 
gaming industry captured the idea of interactive multiplayer games. Today there are 
many popular Internet-based multiplayer games available. 

Effective networking of diverse entities and systems is a common problem for 
Networked Virtual Environments. In order to communicate with other entities a variety 
of communication protocols are used. Historically these communication protocols are 
“hard coded” into the software system and all nodes that participate in the environment 
must identically implement the protocols to interact with others. These communication 
protocols require authoring and compiling by a trained programmer. When the compiling 
process is introduced to the networked virtual environment, it detracts the extensibility 
and dynamicism of the system. 

This thesis presents the design and development of a Networked Virtual 
Environment model that uses Cross Eormat Schema Protocol (XESP). With this work we 
show that a networked simulation can work for 24 hours a day and 7 days a week with an 
extensible schema based networking protocol and it is not necessary to hard code and 
compile the protocols into the networked virtual environments. Eurthermore, this thesis 
presents a general automatic protocol handler for schema-defined XME document or 
message. Additionally, this work concludes with idea that protocols can be loaded and 
extended at runtime, and can be created with different-fidelity resolutions, resulting in 
swapping at runtime based on distributed state. 
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INTRODUCTION 


A. PROBLEM STATEMENT 

The term Networked Virtual Environment (Net-VE) is defined as follows 
“A networked virtual environment is a software system in which multiple users interact 
with each other in real-time, even though those users may be located around the world. 
These environments aim to provide users with a sense of realism by incorporating 
realistic 3D graphics and stereo sound, to create an immersive experience ” by Michael 
Zyda [Zyda 99]. A new networking framework for run-time extensible networked virtual 
environments is presented in this thesis. 

Run-Time Extensible Virtual Environments differ from traditional Virtual 
Environments through the capabilities of run-time discovery and usage of new object 
types and behaviors. Traditional VEs can only operate with objects, behaviors and 
protocols that are present when the VE is started; if any kind of new object, behavior or 
protocol needs to be added to the architecture, the environment mus t be stopped, 
compiled and restarted. NPSNET-V is a Run-Time Extensible Virtual Environment 
implemented by the Naval Postgraduate School (NPS) that uses run-time extensibility for 
new object and behavior discovery. 

Historically communication protocols that are used in Net-VEs are hard coded 
into the software system and all entities that participate in the environment need to 
implement the protocols to interact with others. Introducing a new application layer 
protocol requires off- line authoring and compiling by a trained programmer. This 
compiling process detracts from the extensibility and dynamicism of Net-VEs. 

In RTEVE networking protocols can be loaded and extended at runtime. 
Eurthermore, protocols can be created with different fidelity resolutions which can be 
swapped at runtime, based on the network state. Since the protocols can be tailored to 
best support the requirements of a particular environment, they can enhance network 
performance. These improvements can be made adaptively at run-time by a 
non-professional programmer or by software agents. 
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B. MOTIVATION 

With the dramatic increase in computing and network speed over the past few 
years, Net-VEs have become more widespread. This enhancement introduced the non¬ 
professional programmers into the networked virtual environment area. The main 
motivation behind this thesis was to enable non-adept programmers to tailor their 
networking protocols by using the Extensible Markup Eanguage (XME). 

The NPSNET-V architecture is used to adapt the designed and implemented XME-based 
networking protocol. 

NPSNET-V is used as a framework for development and research in dynamically 
extensible, large-scale virtual environments (ESVEs). The main property of this 
architecture is run-time discovery of new object types and their behaviors. A limitation of 
NPSNET-V architecture is networking protocols which cannot be tailored without 
recompiling and restarting. This limitation detracts the goal of run-time extensibility 
within this architecture. 

C. OBJECTIVES 

This thesis serves two purposes; design and implementation of a user-tailored 
networking protocol which is called Cross Eormat Schema Protocol (XESP), and 
presenting that protocol with different schemas for use in a networked virtual 
environment. 

The networking protocol (using XESP) determines the state changes in entities 
which participate in a Net-VE and is used to exchange state information (e.g. position, 
orientation etc.) between entities. 

In a Net-VE, entities issue packets when their states are changed or when they 
want to keep their states alive in all other participating users. To establish the 
communication between participants, all users (the ones that want to exchange data) must 
agree on the same protocol. The major differences between XESP and hard-coded 
networking protocols is run-time extensibility and flexible ease of use. 
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As it is discussed before, XFSP is based on defining packet formats with 
XML-Schema language. The process behind XFSP can be called XML Serialization, or 
XML marshalling. The basic idea is similar to creating a Document Object Model 
(DOM) pipe between participants. When a user receives a packet into which an XML tree 
is serialized, he or she can build a DOM object tree back from the packet and can retrieve 
the needed data. The position of the data in that DOM object tree is defined by 
XML-Schema. 

Determining the semantics between the DOM tree and entity state is considered to 
have a computational complexity of NP-Hard and is not examined in this thesis. The 
semantic process is defined as being able to know which information to retrieve from an 
information source in order to reflect the output in a Net-VE. Run-time extensibility of a 
semantic process is hard to accomplish and requires thoughtful design. Facilitating the 
expression and distribution of protocol syntax is a major step forward nevertheless which 
enables rapid exploration of efficient and effective protocol semantics. 

Ordinarily, XML is not a compact way to mqrress the data. Messages written in 
XML are much larger than a binary equivalent. The technique that is used to overcome 
this problem is replacing tags with binary tokens. When an XML tree is parsed to 
serialize into an output stream, the tags that mark up the data are replaced with their 
binary equivalents. The end result is a more compact serialized XML tree. 

As it is discussed before, the basic idea behind XFSP was XML-Serialization. 
With this approach, XFSP can be used in any application which needs transactions via 
XML documents such as XML-RPC (XML Remote Procedure Call), XKMS (XML Key 
Management Services), XML-DSig (XML Digital Signatures) and XML-Enc (XME 
Encryption). XESP can present those transactions in a more compact way. 

In this thesis the usage of XESP in a Networked Virtual Environment to exchange 
state information between entities by using the idea of creating DOM pipes between 
participants is presented. Also with this thesis, a PDU Server (Protocol Datagram Unit 
Server) and a PDU Capturer are implemented for servers. The PDU Server program is 
used to continuously send state information from a previously recorded simulation and 
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the PDU Capturer program is used to capture the packets issued by entities from a 
simulation. 

In order to test this new protocol, experiments are conducted across a wide-area 
network (WAN) with George Mason University (GMU) and on a local-area network 
(LAN). 

The results of these experiments are discussed in following chapters. 

D. THESIS ORGANIZATION 

Seven chapters comprise this research: 

• Chapter I-Introduction: Identifies the purpose and motivation behind 
conducting this research. Establishes the goals for the thesis. 

• Chapter Il-Related Work and Background: Provides information on 
Networked Virtual Environments, NPSNET-V, XME, XSD, JXTA, 
SOAP, HEA, DOM4J, DREN and Abilene/Internet2 projects. 

• Chapter Ill-Design and Implementation ofXFSP: Describes the general 
system structure, software components and implementation process of 
XESP. 

• Chapter IV-PDU Farm Implementation: Describes the general system 
structure, software components and implementation process of PDU 
Server and PDU Capturer programs. 

• Chapter V-Binary X3D: Describes the general system structure, software 
components and implementation process of Binary XSD program 

• Chapter VI-Data Collection and Analysis: Explains the results and 
collected metrics from the conducted experiments. 

• Chapter Vll-Conclusion and Recommendations: Explains the conclusions 
and provides recommendations regarding possible future work. 
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RELATED WORK AND BACKGROUND 


A. INTRODUCTION 

This chapter provides an overview to Net-VEs, NPSNET-V, XME, 

XME-Schema, Simple Object Access Protocol (SOAP), JXTA, High Eevel Architecture 
(HEA), DOM4J, Defense Research and Engineering Network (DREN) 

Internet2/Abilene/Next Generation Internet (NGI). 

B. NETWORKED VIRTUAL ENVIRONMENTS (NET-VES) 

A Networked Virtual Environment (Net-VE) is a distributed software component 
with a computer generated simulated space in which multiple users interact with each 
other in real time. The main motivation behind Net-VEs is run-time collaboration 
between participants. 

Each participant uses his or her computer in order to access and collaborate with 
the displayed 3D content. In virtual environments, users are represented by one or more 
entities called avatars. These avatars give the users the illusion of being located in that 
simulated space where the immersive experience is presented. Net-VEs are used for 
multiple purposes varying from education and entertainment to training. Erom a military 
point of view, Net-VEs are a cost effective way to train the war fighters and mimic the 
war scenarios. 

By simulating scenarios in a networked environment, we have opportunity to 
examine the interactions between participants. This examination helps decision makers to 
present new tactics and doctrines for future scenarios. 

A Net-VE system consists of four basic components [Zyda 99]. 

• Graphic Engines and Displays 

• Communication and Control Devices 

• Processing Systems 

• Data Network 
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In this chapter the bottlenecks created by these components in Net-VE systems are 
examined. 

1. Graphic Engines and Displays 

Graphic engines, also called graphics cards, are used to process the 3D content 
generated by some Application Programming Interface (API) (e.g. OpenGL, DirectX) in 
order to make it display able through some output device (such as a computer monitor). 
Display devices vary from 14" Cathode Ray Tube (CRT) to fully immersive 
head-mounted displays. These devices open the three-dimensional (3D) window of the 
virtual environment to the participants. Traditional displays offer only limited immersion 
to the user where they can be distracted by outside light and peripheral vision. For higher 
immersion, users often use Head Mounted Displays (HMDs). HMDs present images 
directly in front of a user's eyes and block out almost all external light. Another example 
for immersive displays is CAVE. CAVE is a five sided cube where the user stands at the 
center and the images are projected to the sides that give a highly immersive experience 
to the participant. 

With the dramatic increase in silicon technology, today we are able to access very 
fast and powerful graphic cards which can render millions of triangles per second with 
pixel shading capability. If the bottlenecks of generating Net-VE content are examined 
from a network programmer point of view, limitations are not the graphic engines and 
displays. 

2. Communication and Control Devices 

The second attribute of a Net-VE system is Communication and Control Devices, 
which are used to manipulate the virtual world objects and communicate with other 
participants in the environment. For manipulation purposes, users typically depend on 
keyboard and mouse. Mouse is a key device for navigation in the virtual environment to 
control the speed of travel and perform other interactions. Incidentally, a keyboard is also 
utilized for typing textual communication and can be used for complicated or less- 
common operations in the environment. 
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Although the keyboard and mouse are the most common control devices, they are 
not the only ones. For game applications the common devices are joysticks, wheel-drives 
or derivatives of these devices. For applications that need more precise manipulation, 
datagloves can be a good candidate. In the near future, with the progress in speech 
synthesizers, voice-recognition applications will be valuable candidates for control 
purposes. 

To achieve full immersion from the Networked Virtual Environment, users should 
be able to communicate with each other. Historically this is done by using keyboard and 
textual communication which is inconvenient for the participants. For example, with 
today’s technology Voice over IP (VoIP) can be an effective way for meeting participant 
communication and collaboration objectives in an integrated fashion. 

3. Processing Systems 

The third component of a Networked Virtual Environment is processing systems. 
A Net-VE system needs a considerable amount of processing capacity [Brutzman 97]. 

The processor receives events from the user’s input devices and computes how these 
inputs can change hosted entity’s positions within the virtual environment as well as the 
location of other entities within the environment [Zyda 99]. The processor also decides 
how and when to notify other users about these state changes. 

In a Net-VE system. Central Processing Unit (CPU) can be easily overwhelmed 
by different computation needs. A physically based modeling exemplar of an E-16 
aircraft can present this heavy-weight computation by processing air dynamics and 
kinematics when precisely modeling the entity. These flight coefficients and quaternion 
mathematic equations [Cooke 92] may be the bottleneck in designing the system. 

As discussed before, a Net-VE system is a distributed software architecture in 
which multiple users interact with each other. In a large-scale Net-VE with many 
participants scenario, without a partitioned network, processing system will be first 
bottleneck in creating this content. In this large-scale Net-VE example, the bottleneck can 
be examined in two ways. Eirst is the buffer (memory) limitation of the computer system 
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in which the environment is simulated, and the second is the cycle limitation of the 
processing unit. This discussion bases the use of XFSP in a Net-VE system where 
sufficient computational horsepower exists to allow users to customize their application 
layer protocol. Fortunately, this overhead is shown to be low, allowing commodity PC 
and laptop devices to use XFSP. 

4. Data Network 

The last component of a Net-VE system is Data Network. This component will be 
examined in more depth to base the discussion on implementing Cross Format Schema 
Protocol (XFSP). 

For several years one of the major factors that limited research into large-scale 
distributed virtual worlds was immature network technology [Macedonia 97]. Immature 
network technology constrained Net-VEs to operate on local-area networks (FANs), 
which limited the number of participating hosts in geographical scope. 

In order to expand this geographical scope and increase number of participating 
hosts, large-scale Net-VEs should operate over Internet, wide-area networks (WAN), and 
exploit its resources. Furthermore, operation over WAN will bring some discussion on 
communication aspects such as bandwidth, latency, distribution schemes, and reliability. 


a. Bandwidth 

Bandwidth is defined as the width of the usable spectrum that is available 
for data signal transmission. The spectrum refers to the range of frequencies that a signal 
contains [Stallings 00]. The bandwidth of the communication link depends on the 
material (media) on which it operates. It can be twisted pair, coaxial cable, fiber optic or 
air. The highest bandwidth among those is in fiber optic cable. 

Bandwidth plays an essential role in determining the richness and size of a 
Net-VE. As the number of participating hosts in a Net-VE system increases so does the 
bandwidth requirement. Additionally, by the nature of virtual environment, a Net-VE 
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system will demand a considerable amount of bandwidth to support video, audio and the 
exchange of 3D content in real time. 


With today’s technology, the networks that have gigabits per second 
bandwidth over Ethernet links or Asynchronous Transfer Mode (ATM) cells are already 
available. Although this enormous bandwidth is present for some users, we cannot 
generalize all users. This efficient use of bandwidth must be considered. 

The discussion on bandwidth determines the scope of target users. In a 
multiplayer game scenario, the target profile is often home users. Although there are 
many promising technologies such as Digital Subscriber Line (DSL) or Cable which can 
provide up to 2 Mbps download and 256 Kbps upload bandwidth, most of the home users 
are still limited to 56Kbps voice modems to join these multiplayer games. Average 
available bandwidth continues to increase each year. 

Because of these reasons, bandwidth plays a crucial role in scalability of 
Net-VE systems. Application-layer protocols thus need to be customized properly to 
satisfy the participant’s needs. 

Well-defined techniques to handle data transmission over the network 
links is a prerequisite for supporting internetworked computer graphics [Brutzman 97]. 

b. Latency 

Network latency is the amount of time required to transfer application data 
from one point to another [Zyda 99]. Latency controls the Net-VE’s interactive and 
dynamic nature, directly impacting the realism of the environment by determining how 
up-to-date is the information received. 

In order to give the players the illusion of being immersed in a networked 
virtual environment, the limits of human perception must be rigorously considered. Lor a 
distributed environment that emulates the real world, Net-VE architecture must deliver 
the packets with sufficiently minimal latency, and generate 3D images at 30-60 Hz to 
guarantee the illusion of reality [Macedonia 97]. 
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Latency is a problematic network component, and Net-VE designers can 
usually do very little about it, because latency is a combination of many constraining 
factors. The first factor to consider is the speed of light. Electromagnetic or optical 
transmission cannot travel faster than that speed. Actually the real propagation speed 
depends on the medium in which the data signal travels, and generally speaking for 
electromagnetic or optical media, it is 2/3 of the speed of light in a vacuum. The second 
factor is the delay introduced by the network. In today’s packet-switched network 
topology data passes through multiple repeater, router and switch hops during its journey 
from source to destination. Most significant are routers which route the packets over the 
network. Each router introduces queuing and processing delays for each packet that 
increases the total amount of delay. The third delay to consider occurs between the 
operating system and network interface hardware on application computers. It takes some 
amount of time for the data to travel from Operating System (OS) kernel to network 
hardware even before it reaches the network. 


c. Jitter 

Given these many factors, users may think that the latency is static and 
cannot change in time. This is not correct statement. Eatency is considered to be a 
stochastic process and cannot be determined precisely, furthermore it will change from 
packet to packet. This change is called “jitter” and is used to define the variation of 
delays. Because of jitter, state changes in a Net-VE system cannot be received at a steady 
rate, thereby degenerating the smooth perception by introducing jerky behavior. In order 
to cope with latency effects, a variety of dead reckoning algorithms are proposed by 
researchers. Specifically, dead reckoning depends on predictive modeling which 
estimates current state of the entity based on previous state, elapsed time and other 
factors. 


d. Distribution Schemes 

Distribution determines the way to transfer data packets from source host 
to destination hosts. There are three ways to transmit data over the network to the users. 
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These are unicast, broadcast and multicast. Distribution scheme is correlated with 
scalability and reliability. Where scalability is defined by the richness of the virtual 
environment and reliability is defined by the data loss rate. 

(1) Unicast: Unicast is a point-to-point communication 
between two end-users. In this scheme only the recipient host and intermediate routers 
need to spend computational cycles during the journey of the packet. With this nature, 
unicast distribution does not scale well for networked virtual environments. In an 
environment with N participants, each host must open N-1 connections and send the same 
data multiple times onto the network. The connection and bandwidth complexity can be 
considered as O (n ) which is clearly an expensive proposition when sending high 
bandwidth streams such as audio and video to multiple users. 

(2) Broadcast: Broadcasting is at the opposite end of the 
spectrum from unicast distribution scheme. Broadcast messages reach every host on a 
local-area network and demand a response from each operating system. This is an 
extremely inefficient way to distribute packets. Even a few small global broadcasts could 
bring the Internet to its knees. Imagine what could happen if a real-time video feed were 
copied to six million Internet users, whether they wanted to watch it or not [Harold 00]. 
That is the reason that broadcasting is prohibited from passing across the switches and 
routers. As it is seen, broadcasting does not scale well for large-scale networked virtual 
environments and limited to the local area networks, furthermore it does not reach 
Internet at all. 

(3) Multicast: There is a middle ground between point-to-point 
communication and broadcasting to the whole world. One way to do this is to create 
static connection trees. This was the solution used by some conferencing systems (e.g. 
CU-See Me). In this example data is fed from the originating site to other servers, which 
replicate it to the other servers, which eventually replicate it to the clients [Harold 00]. In 
this architecture the connection tree does not reflect the best possible network topology to 
distribute the packets and the hooks into the tree must be done manually. It would be 
better to allow the routers to determine the best path for transmitting one-to-many or 

many-to-many type transmission of data. This is where the multicasting comes in. 
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Multicasting is based on the idea of groups. Each host can 
subscribe to any multicast group in order to send and receive data to or from that group. 
Multicasting is done at the hardware level by informing the network interface card (NIC) 
to monitor any specific group. This feature is extremely important since a single high 
bandwidth stream can still reach an arbitrary number of hosts, but computational load is 
only seen on hosts which explicitly subscribe to the multicast channel [Brutzman 97]. 

In order to have multicasting capability and creating one-to-many 
or many-to-many distribution scheme, the routers on the way should be multicast 
enabled. With today’s Internet architecture there are still problems. Most of the routers 
are not multicast enabled; specifically they are not “mrouters”. Current architecture of 
multicasting can be described as the following model. This model describes how end 
systems are to send and receive the multicast packets. 

• IP-style semantics : A source can send multicast packets at any time, with 
no need to register or to schedule transmission. IP multicast is based on 
User Datagram Protocol (UDP), so the packets are delivered using a 
best-effort delivery 

• Open groups : Sources only need to know a multicast address. They don’t 
need to know group membership, and they do not need to be a member of 
the multicast group to which they are sending. A group can have any 
number of sources. 

• Dynamic Groups : Multicast group members can join or leave a multicast 
group at will. There is no need to register, synchronize or negotiate with a 
centralized group management entity. 

This standard IP multicast model is an end-system specification 
and does not discuss requirements for how the network should perform the multicast 
routing. Also it does not propose any mechanisms for providing quality of service (QoS), 
security or address allocation. Actually the major problem here is the routing itself. 

There were many efforts to establish multicast connectivity or 

routing. One of them used handcrafted tunnels across the Internet where the multicast 
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stream is encapsulated with unicast packets. The idea behind this approach was 
establishing UDP channel, IP-encapsulated tunnel, between sub-networks and 
encapsulating multicast data with UDP packets. This model was called MBone. The 
MBone carried its first worldwide event when 20 sites received audio from the meeting 
of the IETF in San Diego in 1992 [MBoneIntemet2]. The most significant achievement 
was the deployment of a virtual multicast network. The multicast routing function was 
provided by workstations running a daemon process called mrouted, which received 
unicast-encapsulated multicast packets on an incoming interface and then forwarding the 
packets over the appropriate set of outgoing interfaces. Routing decisions were made 
using Distance Vector Multicast Routing Protocol (DVMRP), which is based on reverse 
shortest path tree?,. 

Actually these discussions brought the idea of intra and inter 
domain multicasting. For intradomain multicasting new solutions showed themselves, 
such as MOSPF (Multicast Extensions to Open Shortest Path First) where MOSPF 
routers flooded the group membership information to other MOSPF routers or newer 
protocols PIM-DM (Protocol Independent Multicast Dense Mode) and PIM-SM 
(Protocol Independent Multicast Sparse Mode) where they use an existing unicast routing 
table to build a multicasting table. The difference between dense and sparse mode is the 
mechanism that they use for multicasting, such as broadcast-and-prune or explicit join. 
Broadcast-and-prune method is considered to be the dense, and explicit join is the sparse 
mode. 

For interdomain multicasting the solution was BGP (Border 
Gateway Protocol) which supports the routing by reliably exchanging network 
reachability informatbn between border gateways where a network administrator can run 
any protocol within his/her domain. 

Despite all these accomplishments, the multicasting is still not 
widely deployed; most of the routers drop every multicasting packet that hits its incoming 
interface. Multicasting is not the only problem with today’s Internet architecture, QoS 
issues are still not solved, IPv6 is still not supported and there are problems with 
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bandwidth issues. These topics will be discussed in Intemet2 / NGI (Next Generation 
Internet) section. 


e. Reliability 

Reliability typically measures how much data is lost by the network 
during its journey from source to destination [Zyda 99]. In reliable systems it is assumed 
that when data is sent it is always received. Reliable transport protocols use 
acknowledgement and error-recovery schemes. Unfortunately this introduces 
considerable amount of delay and inefficient use of bandwidth to the system. As we saw 
before, real-time systems need fast transmission and high-bandwidth capacity. With these 
acknowledgement, error recovery and congestion control components it is not practical to 
implement both reliable and real-time networked virtual environments. Consequently, 
most of the Net-VE systems use unreliable transport protocol (UDP over IP based 
networks). These systems have been designed to recover from a lost packet and it is not 
crucial to lose a state information packet when the next one is going to be received a 
short time later. 

The Transmission Control Protocol (TCP) is the reliable transport protocol 
that sits on top of the Internet Protocol (IP). TCP uses acknowledgement, sequencing, 
error-recovery and flow-control schemes to achieve its functionality. Another transport 
protocol is User Datagram Protocol (UDP), which is very different than TCP. It offers 
best effort delivery without any promise of sequencing. 

Although it depends on the architecture that the user wants to implement, 
in most of large scale Net-VEs hybrid systems are used. In hybrid systems, both of the 
transport protocols run at the same time for different purposes. TCP can be used for 
managerial and UDP can be used for state exchange objectives. 

Multicasting is implemented by using UDP, however there are many 
efforts in developing reliable (partial) and scalable multicast services by using designated 
receivers and other ideas [Pullen 95] and [Pullen 00]. 
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C. OVERVIEW OF A RTEVE (NPSNET-V) 

The NPSNET program of Naval Postgraduate School started in 1990 as a research 
platform for networked virtual environment technology. It is now its fifth iteration known 
as NPSNET-V [Salles 02]. NPSNET-V is implemented to meet the following goals. 

• Run-time extensibility of both content and applications 

• Scalability in world complexity and number of participants 

• Composability of heterogenous content and applications 

As stated by McGregor and Kapolka, implementers of NPSNET-V, the dream of 
NPSNET-V is for it to be “... a framework for fully distributed, component-based, 
persistent, networked virtual worlds, extensible at runtime and scalable to infinite size on 
the Internet” [McGregor 01],[Salles 02]. 

A full description of NPSNET-V architecture is too extensive for the scope of this 
work; therefore only an overview of the components that play an essential role in XESP 
scope will be covered. Readers can refer to [McGregor 01], [Kapolka 02], [Salles 02] and 
[Capps 01] for more detailed description. 

1. Components 

NPSNET-V is a component-based framework and used to build virtual worlds by 
combining modules at run-time. The run-time extensibility of NPSNET-V does not 
depend on prior knowledge of individual modules. Eurthermore, new behaviors 
(new components) can be added to the system “on-the-fly”. 

NPSNET-V can divided into five functional areas [Salles 02] 

• Configuration Eiles: the blueprints of NPSNET-V 

• Communications: the communication infrastructure of NPSNET-V 

• Database: the database of all necessary data for NPSNET-V 

• Components: the functional code modules used to build VE 

• Temporal: time coordination system 
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Network communication architecture is examined next with regard to the new 
framework called XFSP. 

2. Network Communication Architecture 

NPSNET-V is implemented to handle unicast, broadcast and multicast channels 
as well as using reliable or unreliable transport protocols. 

There are three types of communications performed in NPSNET-V architecture. 

• Administrative Communications which deal with required exchanges of 
necessary components. TCP type connections are used. 

• Object Communication; which deals with passing of object code, modules 
and terrain data from HTTP or specialized servers. They can be 
transmitted over reliable or unreliable connection schemes. 

• Entity Communication which deals with state exchanges. Both reliable 
and unreliable transport schemes might be used. Eor the scalability of the 
environment unreliable transport protocol over multicast distribution 
scheme is preferred. Until recently Distributed Interactive Simulation 
(DIS) (IEEE 1278.1) was used to exchange state information between 
entities. With this work, a new type of entity state exchange protocol, 
XESP, is introduced to the NPSNET-V architecture. XESP exploits the 
idea of XME-Serialization and DOM-Pipe generation. Design and 
implementation of XESP will be examined in Chapter III. 


D. XML 

Extensible Markup Eanguage (XME) is a markup language used to describe the 
structure of data in meaningful ways. The most well known XME applications are web- 
related, but there are many other non-web based applications where XME is considered 
to be very useful for solving specific problems. An example for this type of usage is the 
financial transactions between different businesses. 


16 



XML can be used in many applications varying from databases to extensible 3D 
environments. Actually it can be said that XML is to be used in any application where 
“data” is processed, which results in “every” application. 

With today’s evolving technology, XML is considered to be the solution for many 
problems in computer world. In my opinion the biggest problem is the interoperability 
between non-homogenous systems. The differences between these non-homogenous 
systems can be summarized in four major points. 

Computer Architecture 

Operating Systems 

Data Structures 

Programming Language 

Being a W3C standard, XML is a simple text document which describes the 
actual data with meta-data. Any programming language running on any platform can 
parse this text document and interpret it to its internal data structure. With this nature, 
XML is the solution for system integration and interoperability problems in non- 
homogenous systems. Reader can refer to [Hunter 01] and [W3CXML] for more 
information on this topic. 

E. XSD 

An XML Schema is the modeling document which defines the structure of an 
XML document. Schemas are used to validate the XML documents. 

XML Schema uses the same syntax that XML uses, it fully supports the 
Namespace Recommendation and allows creation of complex and reusable content 
models with the idea of object inheritance and type substitution. 

The fundamental idea behind validation is to create XML documents that they can 
be shared by multiple users without any conflict when they follow the same rules that the 
schema defines. Any well-formed XML document can be validated against any schema. 
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There are many open-source XML Schema parsers and XML validators which 
can be downloaded from web-sites. The basic process of XML validation is shown in 
Figure 2.1. 
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Figure 2.1: XML Validation Using Schema 
In XFSP, XML Schema is used to define the application layer protocol format in 
a Net-VE platform for participating users. The complete process of XFSP will be 
discussed in Chapter III. For now, the fundamental idea is creating a schema parser over 
top of a non-commercial schema parser where it can parse the schema to properly define 
the protocol syntax. 

For more information about XML Schema and schema parsers refer to 
[WSCSchema]. 

F. JXTA 

JXTA Project is an open-source technology which is about communication, 
collaborations and sharing. The JXTA applications vary from instant messaging to 
transactional web services to interactive gaming. This technology provides an open, 
generalized platform for building peer-to-peer (P 2 P) applications. 

JXTA provides a set of simple and flexible mechanisms for enabling devices such 
as cell phones, wireless PDAs, PCs and servers to act as peers on a virtual network. As a 
peer, any connected device can establish ad hoc networks to find, access and use the vast 

resources of other peers on the network regardless of location [JXTA]. 
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JXTA protocols establish a virtual network on top of existing networks, hiding 
their underlying complexity. Unlike traditional client-server networks which rely on a 
centralized point of message transport, a JXTA virtual network allows peers to interact 
with other peers or resource directly, even across firewalls or different network 
boundaries. In order to cross firewall problems, JXTA uses HTTP tunneling over port 80. 
Most of firewall administrators consider port 80 as safe and allow communication 
connections on that port. JXTA exploits this idea and crosses firewall boundaries. 

Today, companies in diverse industries such as wireless telecommunications, 
government, entertainment, financial services and educations have started using and 
evaluating the JXTA technology. 

For example in the telecommunications industry, JXTA technology enables the 
creation of ad hoc wireless networks. In the media and entertainment industry, developers 
are exploring the use of P 2 P technologies for a new generation of interactive and 
participative games. 

The power of JXTA comes in building virtual networks quickly for short-term 
projects as well as for long ones without needing to create separate, costly and complex 
infrastructures. 

JXTA may not seem a solution for ah of the networking infrastructure needs, but 
it is a promising technology for creating ad hoc virtual networks for distributed 
computing. 


G. SOAP 

In order to understand SOAP (Simple Object Access Protocol) we must have a 
firm understanding of basic concept of web services. A web service is a network 
accessible interface to application functionality, built using existing Internet technologies 
[SOAP]. Web services is an interface positioned between the application code and the 
user of that code. It acts as an abstraction layer, separating the platform and programming 
language-specific details of how the application code is actually invoked. This process of 
abstraction is shown in Figure 2.2. 
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Figure 2.2: SOAP Web-Services Abstraction [SOAP] 

SOAP’s place in the web services is as a standardized packaging protocol for the 


messages shared by different applications. The SOAP specification defines nothing more 
than a simple XML-based envelope for the information being transferred and a set of 


rules for translating application and platform-specific data types into XML 
representations (XML Marshalling and XML Unmarshalling). 


SOAP is just an XML document relying on XML standards like XML Schema 
and XML Namespaces for its definition and functionality. SOAP is a basic XML 
Messaging where applications exchange information. It provides a flexible way for 
applications to communicate. 

An XML message can be anything: a purchase order, a request for current stock 
price or current position of friendly forces. The XML messaging process is shown in 
Figure 2.3. 


Application 



Application 


Figure 2.3: XML Messaging [SOAP] 

Because XML is not tied to any particular application, operating system or 
programming language, XML messages can be used in all environments. A Unix-based C 
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program can create an XML document representing a message and send it to a Windows 
Java program where it can be interpreted without any conflict. 

The fundamental idea is that two applications, regardless of operating system, 
programming language or any type of technical implementation detail, may share the 
information using nothing more then a simple message encoded in a way that both 
applications understand. 

This was at the heart of XFSP, where SOAP-like XML messaging is used to 
transmit entity state information. In order to gain from the bandwidth, XML element and 
attribute names are replaced by binary short tags and XML document is serialized into 
packets. The complete process of XFSP will be discussed in Chapter III. 


H. HLA 

The High Level Architecture (HLA) is a software architecture that can be 
considered as the glue which allows users to combine computer simulations into a larger 
simulation [HLA 00]. HLA helps to create a big simulation from pieces; the fundamental 
idea is component-based simulation. 

For instance, there may be a need to combine simulations in several different 
regions with simulators running on different machines, such as Fast Patrol Boats, Frigate 
Divisions, Amphibious Ships, Tactical Air Support Maritime Operations (TASMO) 
Aircrafts to create a navy battle simulation. HLA combines these standalone simulations 
into a single and combined simulation with the ability to extend it in the future by adding 
new simulations. 

In order to be familiar with the HLA framework, some new terms are introduced 

below. 

Federation: Federation is the combined simulation system created from the 
existing simulations. 

Federate: Federate is the each simulation that is combined to form a 

federation. 
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Federation Execution: Federation Execution is a session of a federation 
executing together. 

A federation contains a supporting software called the Run-time Infrastructure 
(RTI), a common object model for the data to be exchanged between federates 
(simulations) in a federation called the Federation Object Model (FOM) and a number of 
federates [HFA 00]. 

In the HFA framework, one federate might represent one platform such as a Fast 
Patrol Boat, or a federate might represent an entire Fast Patrol Boat Division. From the 
perspective of HFA, a federate is defined by its single point of attachment to the RTI. 

As shown in Figure 2.4, a federate might model some number of entities, or it 
might have a different purpose such as just being a data collector by passively receiving 
data and generating none. 





Interface 


Run-time Infrastructure 


Figure 2.4: Software Components in HFA [HFA 00] 


The fundamental idea behind the HFA is software reuse. Design goals of the HFA 
are listed below. 

• It should be possible to decompose a large simulation problem into 

smaller parts. Smaller parts are easier to define, build correctly and verify. 
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• It should be possible to combine the resulting smaller simulations into a 
larger simulation system 

• The functions that are generic to component-based simulations systems 
should be separated from specific simulations. The resulting generic 
infrastructure should be reusable from the one simulation system to the 
next. 

• The interface between simulations and generic infrastructure should 
isolate the simulations from the changes in the technologies [HLA]. 

With regard to these goals, the HLA is foremost a software architecture, rather 
than a particular implementation of its infrastructure. It contains a variety of different 
implementations. Consequently, it is defined not by the software, but by a set of 
documents. 

Currently the HLA is an IEEE standard as the IEEE 1516 specification. Eor more 
information about the HEA the reader can refer to [HEA 00], [HEADMSO] and 
[HEAIEEE]. 

1. DOM4J 

DOM4J is a Java toolkit for writing XME processing applications, with its own 
tree-based model for XME documents, inspired by the XPath data model 
[DOM4JCook 01]. It has both event-based and tree-based modes, supports evaluation of 
XPath expressions against the document tree, and also has an implementation of its own 
tree model that supports the DOM. 

The current implementation of XESP uses DOM4J API in order to accomplish 
XME processing. XME processing includes a number of sub-components such as XME 
Serialization, XME Deserialization, XME Schema Parsing and XPath Addressing. 
DOM4J is chosen to be the API for this project for the following reasons. 
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• Open-Source: It is an open-source project where the source of the 
complete API can be downloaded, inspected and customized (as 
necessary) according to the user needs. 

• Easy-to-Use: It is a Java-based API, easy-to-use and intuitive for a Java 
programmer. It takes best features from DOM and SAX and puts them 
together. 

• Standards Compliant: It fully supports DOM and SAX together with 
existing Java platform standards such as Java 2 Collections and J2EE. 

• Complete XPath Integration: Complete XPath support is integrated into 
the API. XPath is the ideal technology for navigating around XME 
documents simply and easily. 

• Handle Very Earge Documents: It is fast and efficient with small memory 
overhead for parsing, where it can process large XME documents with the 
support of XPath, XSET and XME Query. 

With DOM4J, users are able to create their own XME tree implementations by 
simply providing a DocumentEactory implementation where it can support dynamic data 
binding to XME tree nodes. 

Eor further details about DOM4J API, reader should refer to DOM4J Cookbook 
[DOM4JCook 01] and on-line documentation [DOM4JOnline]. 

J. DREN 

The Defense Research and Engineering Network (DREN) is DoD’s high- 
performance network. The DREN is a robust, high-speed network that provides 
connectivity among geographically dispersed user sites and shared resource centers. The 
networking services of DREN are provided by a contract service where the service 
provider has built DREN as virtual private network (VPN) over a public infrastructure. 
The DREN provides digital data transfer services between defined service delivery points 
(SDPs). SDPs are specified in terms of wide area networking (WAN) bandwidth access. 
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network protocols (Multi Protocol Label Switching, IP, ATM) and local connection 
interfaces [DREN 03]. 


DREN currently supports bandwidths from DS-3 (45 Mbps) at user sites to OC-12 
(622 Mbps) at selected centers. Euture bandwidths will scale to OC-192 (10 Gbps) and 
beyond. The sites to be connected by DREN services may be at virtually any point in the 
continental Unites States, Alaska and Hawaii. 

Incorporating the best operational capabilities of both the DoD and the 
commercial telecommunications infrastructure, DREN is the official DoD long- haul 
network for computational research and testing. DREN enables many scientists and 
engineers at defense laboratories, test centers, universities and industrial sites to use 
high-performance computing resources. 


K. INTERNET2/ABILENE/NGI 

The rapid growth of Internet in the number of hosts, number of users, traffic level, 
traffic nature and topology complexity has often resulted in the degradation of Quality of 
Service (QoS) available to the end-users. Some replication techniques, such as caching of 
recently accessed information and deliberate mirroring are used to reduce the Internet 
traffic. Nevertheless, problems are common. 

The growing interest in multimedia applications had huge impact both on 
telecommunication networks and the Internet. With current Internet’s best-effort delivery 
it seemed not quite possible to support applications which need differentiated services, 
real-time streaming or real-time collaboration. These developments led the education and 
research community to think about a Next Generation Internet (NGI). The Intemet2 
initiative provided a forum for the universities and research communities interested in 
NGI activity [Ghonaimy 99]. 

The Internet2 project aims at serving the education and research community and 
is mainly a joint project among universities mostly in United States. A release project is 
the Next Generation Internet (NGI) which is envisaged to cope with demanding new 
applications in all fields. The ultimate objectives of Intemet2 are: 
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Developing a fast all-optieal network 

Using more efficient switches and routers where IPv6 is supported 
Developing the new multicasting technology 
Putting an emphasis on end-to-end QoS 


The first stage of Internet! relied on the vBNS (the very high-speed Backbone 
Network Service), but later developed its own backbone called Abilene, announced in 
April 1998 [Ghonaimy 99]. 


The Abilene backbone network provides high-performance, best-effort delivery 
for U.S. nationwide connectivity to Internet! universities and their institutions. The Naval 
Postgraduate School is one of the members of this community. Abilene is a pure packet- 
over-SONET (POS) network providing coast-to-coast OC-48 (!.4 Gbps) IP transit. 
Connectors attach to one of the POPs (Point of Presence) with either POS or 


IP-over-ATM access circuits, running at OC-3 (I55Mbps), OC-I! (6!! Mbps) or OC-48 
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Figure !.5: Abilene Network Logical Map [Abilene 00] 
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With Abilene, Intemet2 and NGI projects, the research community is trying to 
find answers to the needs of real-time interactive applications which typically support 
human-to-human collaboration or human-to-machine remote control. This demand of 
interactivity imposes stringent worst-case delay, jitter and loss requirements on the 
underlying network service. These applications often demand worst-case network 
performance bounds that must be maintained on any time interval longer than a few 
milliseconds. 

In order to accomplish these achievements, researchers are trying to extend 
current Internet technology with the ones that discussed above. Current Internet 
technology is a single-service network where all packets are treated almost same. Many 
research efforts are contributed to bring solution to the QoS problems and provide a 
better technology. With all these efforts it seems quite promising to have a high-speed 
Internet which fully supports IPv6 and differentiated services in the near term. 


L. RELATED WORK 

1. An Automated Approach to Distributed Interactive Simulation (DIS) 
Entity Development 

Michael Canterbury’s thesis tried to solve the limitation of DIS protocol for large- 
scale Net-VEs. In that thesis, Canterbury targeted the DIS support for real-time, 
simulated engagements of more than 1000 entities. In order to solve that problem, 
Canterbury refined the existing DIS protocol and optimized the form and content of DIS 
network traffic [Canterbury 95]. 

The approach taken was to design and build a protocol development tool which 
was accomplished in three phases. In the first phase, a modified Backus-Naur Form 
(BNF) grammar was formulated for use in modeling DIS data elements. In the second 
phase, the grammar was applied to the PDUs and data types specified in DIS standard. In 
the last phase, a tool, the DIS Protocol Support Utility, was developed as a means to 
automate the process of authoring, editing and implementing refinements to the DIS 
protocol. 
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As a result of this effort, Canterbury specified the data elements depicted in DIS 
standard by using a BNF-like grammar. With the implementation of Protocol Support 
Utility, the generated grammar was parsed and program source code associated with each 
data element automatically generated. The conclusion that the framework reached was 
[Canterbury 95], 

• A modified BNF grammar can be used to describe DIS protocol entities. 

• A simple grammar might be used to model the data elements associated 
with a complex protocol. 

• Though the modified BNF syntax was suitable for modeling the PDUs and 
data entities associated with DIS, it was not well suited for modeling the 
methods or implementation details needed in processing those entities. 

For further information about run-time protocol extensibility, reader should refer 
to [Zeswitz 93], [Canterbury 95] and [Fischer 01]. 

2. Wireless Access Protocol (WAP) Wireless Markup Language (WML) 
Specification 

Wireless Application Protocol (WAP) is a result of continuous work to define an 
industry-wide specification for developing applications that operate over wireless 
communication networks. The WAP Forum, originally founded by Ericsson, Motorola, 
Nokia, and Unwired PlanetWML was formed to create the global wireless protocol 
specification that works across differing wireless network technology types, for adoption 
by appropriate industry standards bodies. To enable operators and manufacturers to meet 
the challenges in advanced services, differentiation and fast/flexible service creation, 
WAP defines a set of protocols in transport, session and application layers [WAP 99]. 

The WML specification designed by WAP Forum defines a compact binary 
representation of the XML. The binary format was designed to allow for compact 
transmission with no loss of functionality or semantic information. The format is 
designed to preserve the element structure of XML, allowing a browser to skip unknown 
elements or attributes. The binary format encodes the parsed physical form of an XML 
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document, i.e., the structure and content of the document entities. Meta-information, 
including the document type definition and conditional sections, is removed when the 
document is converted to the binary format. 

Based on XML, Wireless Markup Language (WML) is intended for use in 
specifying content and user interface for narrowband devices, including cellular phones 
and pagers. WML includes four major functional areas [WAPW3C]: 

• Text presentation and layout: WML, including image support and a 
variety of formatting and layout commands. 

• Deck/card organizational metaphor: All information in WML is organized 
into a collection of cards and decks. 

• Inter-card navigation and linking: WML includes support for explicitly 
managing the navigation between cards and decks. 

• String parameterization and state management: All WML decks can be 
parameterized, using a state model. 

3. Compressing XML with Multiplexed Hierarchical Prediction hy 
Partial Match (PPM) Models (XMLPPM) 

XMLPPM is a data compression program that compresses XML files. It is a 
combination of the Prediction by Partial Match (PPM) algorithm for text compression, 
and an approach to modeling tree-structured data called Multiplexed Hierarchical 
Modeling (MHM) developed by Cheney [XMLPPM]. 

The main idea behind XMLPPM is leveraging the work that a Simple API for 
XML (SAX) parser does by encoding the sequence of events. An implemented decoder 
decodes these events, and reconstitutes an XML document equivalent to the original. 
Alternatively, the decoder acts as a SAX parser, parsing encoded event sequences instead 
of text, and sending those events directly to the application. 

In XMLPPM, a single byte event encoding is used to encode element start tags, 
end tags and attribute names and to indicate events such as “begin/end characters, 
begin/end comment”, and so on. The encoder and decoder maintain consistent symbol 
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tables; whenever a new symbol is encountered, the encoder sends the symbol name and 
the decoder enters it to the table [XMLPPM]. 

Additional to the SAX type encoder/decoder, in XMLPPM a Multiplexed 
Hierarchical Modeling is used. This technique employed two basic ideas: multiplexing 
several text compression models based on XML’s syntactic structure (one model for 
element structure, on for attributes and so on) and injecting hierarchical element structure 
symbols into the multiplexed models. With these techniques XMLPPM claims that it can 
compress XML files from 5 to 30% better than any existing text or XML-specific 
compressors. Further information about XMLPPM can be found at [XMLPPM] and 
[XMLPPM 03]. 

4. XMill 

XMill is an XML-conscious compressor that compresses XML documents by 
using the redundancy and standard text compression approaches. XMill combined with 
gzip compresses XML data about 10% better then gzip on equivalent non-XML 
forms; further improvement (up to 50%) is possible with user assistance in the form of 
complex command-line parameters [XMill 00]. 

XMill shows that XML-conscious compression can do better than text 
compression alone. XMill applies three principals to compress XML data [XMill 00]. 

• Separate structure from data: The structure consisting of XML tags and 
attributes is compressed separately from the data. 

• Group related data items: Data items are grouped into containers, and each 
container compressed separately. 

• Applying semantic compressors: XMill can apply specialized semantic 
compressors to different containers. 

However, XMill’s base transformation has several drawbacks, it requires user 
assistance to achieve best compression, and it wins only if the data set is large, typically 
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over 20 KBytes because of the additional bookkeeping overhead and the fact that small 
data containers are poorly compressed by gz ip. 

For further informatbn about generic and XML-specific compression schemes 
reader should refer to [ZLib], [BinXML], [XMill 03] and [Millau]. 

M. SUMMARY 

In this chapter Net-VEs, NPSNET-V, XME, XME-Schema, SOAP, JXTA, HEA, 
DOM4J, DREN, Internet2/Abilene/NGI are discussed. Additionally, related works such 
as An Automated Approach to Distributed Interactive Simulation (DIS) Entity 
Development, WME, XMEPPM and XMill are introduced to provide the background and 
reasons for this thesis research. 


31 



THIS PAGE INTENTIONALLY LEET BLANK 


32 



m. CROSS FORMAT SCHEMA PROTOCOL (XFSP) 


A. INTRODUCTION 

This chapter introduces the description, design and implementation detail of Cross 
Format Schema Protocol (XFSP). This general XML compression scheme can be used 
for automatic production of binary network protocols, and binary file formats, for any 
data structures specified in an XML Schema. 

B. OVERVIEW OF XFSP 

The idea of creating flexible and run-time extensible application layer protocols 
inspired the implementation of XFSP. The question to be answered was “How can a run¬ 
time extensible application layer protocol be implemented?” After preliminary searches 
in published papers and different software architectures, XML appeared to be an 
excellent approach for describing data structures. Specifically, XML-Schema can be used 
to define the protocol syntax. Because the protocols are considered to be the definition 
language describing the agreement between end-users and end-systems, they can be 
described well by XML-Schema using its internal as well as user defined data structures. 

In order to accomplish this, a schema parser is implemented on top of an open- 
source XML parser called DOM4J [DOM4JOnline 03]. That schema parser parses the 
provided schema and creates entries in a table for each element and attribute defined in 
the schema document. The need for this process is to be able to send the XML documents 
in a more compact way by exploiting the protocol (i.e.'"agreement”) notion. Initial tests 
showed that a short XML document can go beyond the MTU (Maximum Transmission 
Unit; i.e. 1500 bytes for Ethernet) very easily. The solution for that problem came with 
binary XML or XML Serialization. Instead of sending the XML document as a serialized 
text, a replacement algorithm might be used that replaces the element and attribute names 
with short tag numbers to serialize the data. 

Because the protocols are defined as an agreement between user applications and 
if users agree on using the same protocol via the same schema, then there is no need to 
send the whole name for each element and attribute. This may raise the question why a 
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DIS- like (Distributed Interactive Simulation) [DIS] protocol is not used instead of XFSP. 
Actually the answer for this question is obvious. First, in DIS-like protocols the syntax of 
the protocol is static and all of the data must be in their previously specified places, so 
there is no way to send a subset or selected section of the whole protocol. The second 
reason is that such protocols are not run-time extensible. The syntax of the protocol 
cannot be changed while the application is running. The last reason is the serialized data 
can be converted easily back to the text and can be used in web-service applications l ik e 
SOAP. 

With XFSP two main ideas are implemented: changing the protocol syntax at run¬ 
time and XML Serialization / Deserialization. The problem domain is targeted to meet 
the needs of non-homogenously distributed users, where non-homogeneity is primarily 
described as the bandwidth distribution. Although fast networks are already present in 
today’s networking infrastructures, users are still non-homogenously distributed and 
cannot always access high bandwidth. The idea of changing the protocol at run-time to 
meet the needs of the different users at different fidelity levels is considered as a valuable 
problem to address. 

The following sections cover the design and implementation details of XFSP. 


C. PROTOCOL DESCRIPTION VIA XML SCHEMA 

The key elements of a network protocol can be described as: 

• Syntax: Describes the format and the position of data. 

• Semantics: Describes the functional connection between application and 
data. 

For the XFSP project, semantics is not targeted to be solved and is generally 
considered to be NP-Hard, because the semantic definition needs a knowledge domain 
and AI generation. As described before, the run-time extensible syntax is pointed out as 
the research question and targeted to be solved. To solve this problem, XML Schema is 
used to define the application-layer protocol between users and serialized XML data is 
sent as the payload. 
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An exemplar application layer protocol is shown in Figure 3.1, where it is defined 
by using XML Schema. 


<?xml version="1.0" encoding="UTF-8"?> 

<!- Edited with XML Spy v4.3 by Ekrem Serin (NFS) -> 
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema " 
elementEormDefault=: "qualified "> 

<xs:element name= "protocol"> 

<xs:complexType> 

<xs:al]> 

<xs:element name= 'header" type="HeaderType"/> 
<xs:element name= "location" type= ' YectorSDouble "/> 
<xs:element name= "velocity" type=='Yector3Eloat"/> 
</xs:al]> 

</xs:complexType> 

</xs:element> 

<xs:complexType name="HeaderType "> 

<xs:al]> 

<xs:element name= "version" type="xs:short"/> 
<xs:element name="exerciseID" type="xs:byte "/> 
<xs:element name="pdutype " type="xs:int"/> 

</xs:al]> 

</xs:complexType> 

<xs:complexType name='Yector3Double "> 

<xs:attribute name="x" type="xs:double "/> 

<xs:attribute name="y" type="xs:double "/> 

<xs:attribute name="z" type="xs:double "/> 
</xs:complexType> 

<xs:complexType name='Yector3Eloat"> 

<xs:attribute name="x" type="xs:float"/> 

<xs:attribute name="y" type="xs:float"/> 

<xs:attribute name="z" type=:"xs:float"/> 

</xs : complexT y pe > 

</xs:schema> 


Figure 3.1: A Simple Schema Document 
This schema shows that there are three top level elements, header, location and 
velocity, that are connected to the root element called protocol. The data type of header is 
a custom type called HeaderType and the data types of location and velocity elements are 
custom type as well, VectorSDouble and VectorSFloat respectively. If the HeaderType is 
examined, it has three elements, version as short type, exerciselD as byte type and 
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pduType as integer. VectorSDouble and VectorSFloat define three attributes such as x, y 
and z as double or float types respectively. 

If the protocol hierarchy tree is examined (Figure 3.2), it can be represented by a 
tree structure as follows. Elements are shown by boxes and attributes are represented by 
ellipses. 



Figure 3.2: Tree Representation of Example Schema 


The extensibility also shows itself in this tree representation, that the protocol can 
be described in different ways; i.e. the attribute and element locations do not have to be at 
the exact place in a PDU as it is in DIS. Another legitimate representation for the same 
protocol payload is shown in Figure 3.3. 



Figure 3.3: Alternate Tree Representation of Example Schema 

36 

























Another area for extensibility might be the capability to send a subset of this 
protocol tree to users who do not need to know the whole data set. XFSP can also handle 
this selective transmission process. 

The implementation detail of XFSP is examined in the following sections. The 
UML diagrams shown in Figure 3.4 and Figure 3.5 provide background information 
about the class hierarchy of the XFSP Project. 


::org.npsnet.xfsp 


DocumentProcessorXSD 

] DocumentProcessorX3D(.-.) 

3 DocumentProcessorX3D(...) 

3 DocumentPfocessofX3D(...) 

3 DocumentPfocessofX3D(...) 

3 getDocumentf...) 

3 serializeXMLI...) 

3 setSchema(...) 

3 setTableManager(...) 

3 setXMLDocumenl(...) 

3 setXMLDocumenl(...j 
3 $elXMLDocurrienl(.,' 


DocumentPiocessoi 


3 DocumentProcessot(...) 
3 DocumentProcessot(...) 
3 DocumentProcessot(...) 
3 DocumentProcessot|...) 
3 getTree(...) 

3 seridlizeXMLj...] 

3 setSchema(...) 

3 setTableManager(...) 

3 setXMLDocumenl(...) 

3 seiXMLDocurrienl(..' 

3 $elXMLDocurr>ent(...) 

TableElement 


3 getEndTag(...J 
3 getNarrie[...] 

3 getNewElement(...) 
3 getStaflTag(...) 

3 getTypef...) 

3 isEndTagI.) 

3 isSlartT ag(. 1 
3 setEndTag(...) 

3 se(Name(...) 

3 $e(SlaftTag(...) 

3 TableElement(...) 

3 toStiing(...) 


DOMManipulatoi 


TableAUiibule 


T ableAtUibuteX3D 

IS DOMManipulator(...] 


IS gelName(...) 


® ge(Name(...) 

IS gelDatd(...) 


IS getNeiiMAttributej...) 


® ge(NewAUribute(...] 

IS $etData(...) 


S getTagl...) 


® ge(Tdg(...) 

IS $etData(...i 


® geHype(...l 


® gelTypel...) 

IS selDataj...) 


ffl $elName(...) 


® setNamej...) 

IS setData(...j 


S setTag(...) 


® setTag(...) 

SI se(Data(...i 


® TableAlt(ibute(...) 


® TableAHribu»eX3D(...) 

IS se(Data(...j 


® toShing(-..) 


® toSlringt.] 

IS $etDatd(...) 




BinaiyReader 


BinaryReadeiX3D 

® currentElemenl: Element 




® currentElement: Element 



® cutrentElemenllnfo: TableElemen&< 



® done: boolean 

® firstElement: boolean 


® elementStack: Stack 

® infoDatabase: TableManager 


® firstElement: boolean 

® parseSlate: ini 


® infoDatabase: TableManagerX3D 

® roolElement: Element 


® parseSlate: ini 
® roolElement: Element 

® BinaryReaderl...) 


® BinaryReadefX3D(...) 

S getDocument(...) 


® getTre^-.j 


® gelDocumentf...) 

® par$eData(...) 


® parseDataf-..) 


TableManager 



3 addSchema(...) 

3 getAHribu(e[.. J 
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3 gei:Elemenl(...) 

3 getElement(..,) 

3 getElementEndTag(...) 
3 getElementStartTagl...) 
3 getEmptyDocument(..) 
3 gelEmptyDocumenli..) 
3 main(.,.) 

3 selSchema(...) 

3 TableManagef{...) 

3 TableManagert..) 


TableManagerXSD 


getAlhibutef...) 

getAttributej...] 

getAKributeTagt-.] 

getElement(,..) 

getElemenlj...) 

getElementEndTag(-..) 
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printAKributeHashT able(...) 
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setSchema(...) 
TableManagefX3D(...) 
TableManagerX3D(...) 


TableElemenlX3D 


3 getEndTag(...) 

3 getName|...) 

3 ge(NewElemenl(...) 

3 getStartTag(...) 

3 getTvpe(...) 

3 isEndTagf...) 

3 isSlartTagl...) 
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3 TabteElefnentX3D(...) 
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Figure 3.4: UML Diagram for Root Directory of XFSP (Generated by [ESS]) 
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::org.DpsDet.ifsp.datat}'pes 



Figure 3.5: UML Diagram for Implemented Data Types corresponding to XML Schema 

and X3D (Generated by [ESS]) 


D. SCHEMA PARSING 

As described before, the data-defining XML Schema is parsed to create the 
application layer protocol. The end product of the parsing process is a look up table 
where element and attribute names and associated data types can be retrieved. 
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The parsing process assigns a unique short number (i.e. token) for start and end 
tags of each element, as well as an element-specific token for each attribute. The process 
also determines the data types used by elements or attributes. The element or attribute 
names do not need to be unique; the schema parser is able to distinguish non-unique 
names. 


If the previous schema document is examined for the parsing process, the 
resultant tables for element and attribute look ups would be as follows (Table 3.1 and 
Table 3.2). 


Name 

Start Tag Number 

End Tag Number 

Datatype 

/protocol 

10 

11 

Null 

/protocol/header 

12 

13 

ComplexType 

/protocol/location 

14 

15 

ComplexType 

/protocol/velocity 

16 

17 

ComplexType 

/protocol/header/version 

18 

19 

XSDShort 

/protocol/header/exerciselD 

20 

21 

XSDByte 

/protocol/header/pduT ype 

22 

23 

XSDInteger 


Table 3.1: Element Look up Table Example 


Name 

Tag Number 

Datatype 

/protocol/location/ @ x 

24 

XSDDouble 

/protocol/location/ @ y 

25 

XSDDouble 

/protocol/location/ @ z 

26 

XSDDouble 

/protocol/velocity/ @ x 

27 

XSDEloat 

/protocol/velocity/ @ y 

28 

XSDEloat 

/protocol/velocity/ @ z 

29 

XSDEloat 


Table 3.2: Attribute Look up Table Example 
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The XPath addressing and tag numbers are used as keys for creating hash tables. 
These keys provide quick access to the elements and attributes during the serialization 
and deserialization processes. The table generation is done in TableManager class. This 
class also provides adding a new schema over the existing ones. In this way, new schema 
documents can be parsed at run-time when new protocols need to be introduced to the 
system. 


Another feature of this class is providing an empty XML document (tree) 
according to the given schema. The capability to provide a sub-tree when the root of the 
requested sub-tree is passed as parameter is further provided. 

The implemented parser cannot handle every schema document. Schema parsing 
operation is a difficult process and many cases need to be handled uniquely. One of the 
difficulties is assigning a unique name to every element and attribute. This is vital 
because it affects the correctness of the serialization and deserialization processes. A 
counter example where unique name assignment might be mishandled is shown in 
Figure 3.6. 


<?xml version='T.0"?> 

<xsd:schema xmlns:xsd= "http://www.w3.org/2001/XMLSchema "> 
<xsd:element name= "SameElementName "> 

<xsd:complexType> 

<xsd:attribute name= "SameAttrName " type='’xsd:boolean"/> 
</xsd:complexType> 

</xsd:element> 

<xsd:element name="AnotherElement "> 

<xsd:complexType> 

<xsd:sequence> 

<xsd:element name= "SameElementName "> 

<xsd: complexT ype> 

<xsd:attribute name= " SameAttrName " type="xsd:int"/> 
</xsd:complexType> 

</xsd:element> 

</xsd:sequence> 

</xsd : complexT ype> 

</xsd:element> 

</xsd:schema> 


Figure 3.6: Example Schema Demonstrating Valid Distinction of Dissimilar Elements 

with Identical Names 
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In this example there are two attributes with different data types but with the same 
name connected to different elements that have the same element name. Figure 3.6 
demonstrates valid distinction of dissimilar elements with identical names. 

Discrimination of over-loaded element names occurs through context-sensitive inclusion 
of parent element inheritance during tokenization. 


<xs:element name="protocol"> 

<xs:complexType> 

<xs:al]> 

<xs:element name="location_l" type="locationType_r7> 
<xs:element name="location_2" type="locationType_2"/> 
</xs:al]> 

</xs : complexT y pe > 

</xs:element> 

<xs : complexType name =" loc ationType_ 1 "> 

<xs:sequence> 

<xs:element name= "location" type='Yector3Floaf7> 
</xs:sequence> 

</xs :complexType > 

<xs : complexType name =" loc ationType_2"> 

<xs:sequence> 

<xs:element name= "location" type= ' YectorSDouble "/> 
</xs:sequence> 

</xs :complexType > 

<xs:complexType name='Yector3Float"> 

<xs:attribute name="x" type="xs:float"/> 

<xs:attribute name="y" type="xs:float"/> 

<xs:attribute name="z" type="xs:float"/> 

</xs:complexType> 

<xs:complexType name=' YectorSDouble "> 

<xs:attribute name="x" type="xs:double "/> 

<xs:attribute name="y" type="xs:float"/> 

<xs:attribute name="z" type="xs:float"/> 

</xs :complexType > 

</xs:schema> 


Figure 3.7: Automatically Amended, Intermediate Example Schema Demonstrating 

Valid Distinction 

In Figure 3.7 the same conflict occurs in a different way where this conflict must 

be resolved before the tag assignment process. If the XPath representation of conflicted 

attributes is examined they can be represented as /protocol/location_ 1/location/@x 

(includes y and z) and /protocol/location_2/location/@x. Although they are bound to the 
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same element name, they are nonetheless unique and thus need to be differentiated. 
Attribute names are also fully qualified by parent elements and types to allow 
distinguishing them despite possible overriding of the same name by multiple many 
different attributes. The schema parser in XFSP handles many of these cases. 


E. XML SERIALIZATION 

The purpose of XML Serialization process is to send XML documents in a more 
compact way. In order to accomplish this, the attribute and element name replacement 
idea is used. The serialization can be considered as the preorder traversal of a given XML 
tree putting all node names and associated data to the output stream. 

XFSP can serialize text-based XML documents as well as Document Object 
Model (DOM) trees. This feature comes with the open-source DOM4J API. 
DocumentProcessor class is implemented to serialize the XML documents or Document 
objects. The UML diagram of DocumentProcessor class is shown in Figure 3.4. 

There are two main constructors for this class. First if the XML document to be 
serialized provides the schema that it implements, that information is used to build the 
look up table. Otherwise the TableManager must be constructed and passed to the 
DocumentProcessor before the serialization method is fired. The following XML 
document (Figure 3.8) implements the schema document provided before. This XML 
document is used as an example in describing the serialization process. 


<?xml version="1.0" encoding="UTF-8"?> 

<protocol xmlns :xs^ "http://www.w3.org/2001/XMLSchema-instance" 
xsi: noN amespaceSchemaLocation= ' 'example, xsd "> 

<locationx="3.45" y= "56.72" ^"-10.1"/> 

<header> 

<exerciseID> 1 </exerciseID > 

<version>l</version> 

<pdutype >2</pdutype > 

</header> 

<velocity x="1.0" y="0.0" z="-0.7"/> 

</protocok> 


Figure 3.8: XML Document for a Sample Protocol 
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If element and attribute tag names are replaced in the serialization process with 
the short numbers looked up from the parsed schema, the above XML document can be 
represented as in Figure 3.9. 


<?xml version="1.0" encoding="UTF-8"?> 
<10 > 

<14 24= "3.45" 25= "56.72" 26="- 10.1" 15> 
< 12 > 

< 20 > 1 < 21 > 

<18>1<19> 

<22>2<23> 

<13> 

<16 27="1.0" 28="0.0" 29="-0.7" 17> 

< 11 > 


Figure 3.9: XML Document with Replaced Tags 
In order to signal specific conditions such as elements that have data or start and 
end of attribute reading, special tokens 0, 1 and 2 are used and these numbers are not 
assigned to any element or attribute in the schema parsing process. The serialization and 
deserialization processes are shown in Figures 3.10 and 3.11. The meanings of tokens and 
tags are also shown in those figures. Tokens are the short numbers signaling deseriali z er 
to change its state. Tags represent the name of the elements or attributes obtained from 
the previously generated look up table. 

Tokenization and de-tokenization are handled in Serializer and Deserializer 
programs. The input for the Serializer is a raw XML documeit as shown in Figure 3.8. 
The output of the Deserializer is the same XML Document. The tokens and tags in the 
Figures 3.9, 3.10 and 3.11 are shown for the clarity and understandability purposes. The 
XML document is not tokenized before entering the Serializer. The tokens and tags are 
present during the transit of the document from the Serializer to the Deserializer. 
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ATag 


: Attribute Token 


AST 


AET 


: Attribute Start Token 


: Attribute End Token 


^iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiirr 


Figure 3.10: XML Serializer and XML Deserializer showing Native Tags 
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Figure 3.11: XML Serializer and XML Deserializer with Tokens and Tags Replaced by 

Short Numbers 
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In Figure 3.11, the Deserializer received the tokens 10, 14 and 1 and started 
building the XML tree gradually. The complete end product of XML Serializer is shown 
in Figure 3.12. The serialized document is interpreted from left to right and top to bottom. 


10 

14 

1 

24 

3.45 

25 

56.72 

26 

-10.1 

2 

15 


12 

20 

0 

1 

21 

18 

0 

1 

19 

22 

0 


2 

23 

13 

16 

1 

27 

1.0 

28 

1.0 

29 

-0.7 


2 

17 

11 


Figure 3.12 : Serialized XML Document 


In order to properly describe, validate and verify the designed algorithm. 
Communicating Finite State Machines (CFSMs) are used [CFSM]. Finite State Machines 
represent the actions taken by Serializer and Deserializer algorithms in serializing XML 
Documents or deserializing them back from the encoded stream. The finite state machine 
diagram of serialization process is shown in Figure 3.15. In this figure, states are 
represented by circles and the arrows between states represent the state changes. The 
valid transitions and failure of transitions are shown in Figure 3.13 and Figure 3.14 



Figure 3.13: Valid Transition 




Figure 3.14: Transition Failure Resulting in Error 
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xml_document 



Figure 3.15: Communicating Finite State Machine (CFSM) Diagram of the Serialization 

Process 


The state table for the CFSM used to validate and verify the serialization process 
is shown in Table 3.3. This table provides information about the purpose and actions 
taken in the states. 
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Name 


Purpose / Action 


Next Input / Transitions 


start 


have element 


Waits for the incoming XML 
Document. When XML 
document is passed in, the 
DOCTYPE, Processing 
Instruction and Schema 
information are removed. 


Waits for the root element of the 
document or the root element of 
the sub-elements. The element 
name is looked up from the table 
and the corresponding tag is put 
into the output stream. 


Input: XML Document. 

Transition : The root element is 
passed to “have element” state. 

Input: Start of the element. 
Transitions : 

1- If data is present, state is 
transitioned to “read content” state 
via data_to_write transition. 

2- If end_of_element is 
encountered, state is transitioned to 
“element complete ” state. 

3- If sub-elements are encountered, 
state is transitioned to itself via 
new_element transition. 

4- If element start tag is not found 
in the look up table, an error is raised. 
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Name 

Purpose / Action 

Next Input / Transitions 



Input: Payload of an element. 


Data Token “0” is put into the stream. 

Whitespace is consumed as 


Content from the XML Document is 

parsed and serialized according to its 

data types such as: 

1- Non-continued data is put 

appropriate 

Transition : 

1-If end of payload is 

read 

directly without putting size 

encountered state is transitioned 

element 

token. 

to '"element complete ” state. 

content 

2- If array type is encountered, 

first the data is parsed and its 

length measured; then the 

2- If payload is a continued 

payload, state is transitioned to 

itself. 


length token and data are put 

3- If the datatype of the 


into the stream. 

corresponding element is not 

found an error is raised. 


Attribute Token “1” is put into the 

stream to signal the incoming 

attributes. This token is used only at 

Input: Payload of an attribute. 

Transition: 


the start of the first attribute. For 

1-If end of payload is 


attribute name the tag is looked up 

encountered state is transitioned 


from the table and written to the 

to "attribute complete” state. 

build 

stream. Data is parsed and handled 

2- If payload is a continued 

attribute 

as; 

payload, state is transitioned to 

payload 

1. Non-continued data is put directly 

itself via the attr_payload 


without putting size token. 

transition. 


2. If an array type is encountered, 

3- If the datatype of the 


first the data is parsed and its length 

corresponding attribute is not 


measured, the length token and data 

found from the look up table, an 


are put into the stream. 

error is raised. 
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Name 


Purpose / Action 


Next Input / Transitions 


element 

complete 


attribute 

complete 


Input: End of the element; next token 
Transition: 

1-If the element to write is the last element 
in the XML Document, state is transitioned 
to state “end”. 

2- If new element is encountered, state is 
transitioned to "‘’have element” state via the 
new_element transition. 

3- If the token corresponding to the 
element is not found from the look up 
table, an error is raised. 

Input: End of the last attribute; next token 
Transition : 

1- If all attributes are handled as indicated 
by receipt of end_of_element token, state is 
transitioned to ""element complete” state. 

2- If a new attribute token is encountered. 

Checks for the new . . . . , ., ,, 

state IS again transitioned to build 

attributes, data for the 

attribute payload" state. 

current element, and new 

3- If token for payload data is 

elements. 

encountered for the element, state is 
transitioned ""read element content” state. 

4- If new element token is encountered, 
state is transitioned to ""have element” state. 


The end token for the 
element is looked up from 
the table and put into the 
stream. 


5- If none of the above tokens are 
encountered, an exception is raised. 
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Name 

Purpose / Action 

Next Input / Transitions 

E 

Error Condition: declares the 

failure of the transition 

In any state errors may occur. The 

reasons for the error state are listed 

below. 

1 - Token numbers cannot be found for 

element or attribute. 

2 - Data serialization cannot be handled 

properly. 

3 - XML Document is not well- formed. 

4- XML Document is not valid. 

end 

Declares the success of the 

serialization process. 

Stream Serialization Complete 


Table 3.3: Serialization Algorithm State Table 


The transition table for XML Serialization is shown in Table 3.4. This table 
identifies the names, purposes, start and end states of the performed transitions in 
Serializer CFSM. The transitions are the changes from the beginning state to the end state 


and occur in the conditions stated in Table 3.3. 


Name 

Purpose 

Start State 

End State 

extract doctype, PI, 

schemas 

Extracts DOCTYPE, 

Processing Instruction and 

Schema Information from 

the XML Document prolog 

and root element 

start 

start 

root_element 

Transition from start to have 

element 

start 

have element 
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Name 

Purpose 

Start State 

End State 

new_element 

Deelares the existanee of 

the new element 

have element 

have element 

attribute complete 

element complete 

new_attribute 

Declares the existence of 

first or new attribute 

have element 

build attribute 

payload 

attribute complete 

end_of_element 

Declares the end of the 

element. 

have element 

element 

complete 

read content 

attribute complete 

data_to_write 

Declares that current 

element has data to write. 

have element 

read content 

attribute complete 

end_of_attr 

Declares the end of the 

attribute is encountered 

build attribute 

payload 

attribute 

complete 

attr_payload 

The payload for this 

attribute is an array type. 

build attribute 

payload 

build attribute 

payload 

continued content 

payload 

The payload for this 

element is an array type. 

read content 

read content 

finished_writing 

Declares the end of the 

document is reached. 

element complete 

end 

white_space 

Removes white space 

between attributes or 

element tags as 

appropriate. 

attribute complete 

attribute 

complete 

read element 

content 

read element 

content 


Table 3.4: Serialization Algorithm Transition Table 
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In order to show how much bandwidth is saved, the previous text-based XML 
Document is sent in four different ways: first by sending the document as a text file; in 
the second and third, serializers JDOM and DOM4J are used, which remove whitespace; 
and in the last one XFSP is used. As seen in Figure 3.16 XFSP provides almost 60% 
compression over the other three methods for this example document. 



F. XML DESERIALIZATION 

XML Deserialization can be defined as recreating the XML tree back from the 
received binary stream. The purpose and implementation detail of sending XML 
documents in a compact way is described in the previous sections. In this section the 
process of deserializing back to the XML document is discussed. 

For deserialization, BinatyReader class is implemented. The UML diagram for 
this class is shown in Figure 3.4. In order to construct a BinatyReader object, a look up 
table has to be created and passed as a parameter to the constructor of the class. That look 
up table is used for finding the element and attribute names and their data types as well. 
The pseudocode for binary reading operation is provided in Figure 3.17. In this operation, 
there can be two main parsing states, such as reading element state and reading attribute 
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state. These states signal the type of reading operation. If the parser is in reading element 
state then it can read a tag that corresponds to the start of an element, or a tag that 
corresponds to the end of the element, or a tag which states that actual data must be read 
next, or a tag which signals that a series of attributes will be read next. 

When the parser enters the attribute-reading state, it can read a tag that 
corresponds to an attribute or a tag which signals the end of reading attributes which 
results with changing the reading state. 


parse_state := element_reading; 
current_element := null; 

function binary_reader () 
do 

if (parse_state = element_reading) 
read_elements(); 

if (parse_state = attribute_reading) 
read_attributes (); 
while (not_end_of_stream) 
end function; 

function read_elenients () 
read_tag(); 
if (element_start_tag) 
create_element(); 
bind_to_current_element(); 
push_to_stack(); 
else if (element_end_tag) 

current_element := pop_stack(); 
else if (data_tag) 
read_data(); 

bind_to_current_element(); 
else if (attribute_start_tag) 

parse_state := attribute_reading; 
end function; 

function read_attributes () 
read_tag(); 
if (attribute_end_tag) 

parse_state: = element_reading; 

else 

read_attribute_tag (); 

create_attribute(); 

read_data(); 

bind_to_cun'ent_element (); 
end function; 

Figure 3.17: Binary Reader Pseudocode 
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As seen in pseudocode, the main approach in recreating the XML document is 
gradually building the tree back by using stack operations. The major steps in this process 
can be seen in Figure 3.18, some in-between steps are skipped to reduce the complexity 
in the figure. 



Figure 3.18: XML Deserialization 
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The Deserializer CFSM is shown in Figure 3.19. This figure defines the algorithm 
used to deserialize the received stream back into the original XML tree. 



found 


Figure 3.19: Communicating Finite State Machine (CFSM) Diagram of Deseriali z ation 

Process 
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The state table for the CFSM used to validate and verify the deserialization 
process is shown in Table 3.5. This table provides information about the purpose and 
actions taken in the states. 


Name 

Purpose / Action 

Input / Transitions 

start 

Waits for the incoming 

stream. 

Input: Incoming serialized stream 

Transition : When the tag for the root 

element is read and looked from the 

table, state is transitioned to ""element 

start” state. 

element start 

The element for the 

deserialized tag is created 

and pushed to the stack. 

Input: Token for the name of the element 

Transition : 

1- If another tag for a new element is 

encountered, state is transitioned to itself. 

2- If end tag for the current element is 

encountered, state is transitioned to 

""element end' state. 

3- When data token is encountered, 

state is transitioned to ""continued data” 

state. 

4- In case that an attribute start token is 

found, state is transitioned to ""attribute 

start” state. 

5- When none of the above tokens are 

found, an exception is raised. 
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Name 


Purpose / Action 


Input / Transitions 


attribute start 


build payload 


Input: The special token “1” which 
indicates the start of the attributes. 
Transitions : 


1-If data type of the current attribute is 
The start tag for the attribute not variable length, state is transitioned 
names is parsed from the ''build payload” state via read_attribute 

stream, then a new attribute transition. 


is created and bound to the 
current element. 


2- If data type of the current element is 
variable length, the state is transitioned to 
"get length” state via arrayjtype 
transition. 


3- When none of the above tokens are 
found, an exception is raised. 

Input: The payload of the attribute 
Transitions : 

1- If start of new attribute is 
encountered, state is transitioned to 
"attribute start” state. 


Builds the payload of the 
current attribute and binds 
the created data object to the 
attribute. 


2- If open or close tag of the element is 
found, state is transitioned to "element 
start” state. 

3- In variable length data case, payload 
of the current attribute is created by 


reading special tags between data blocks. 


4- If continuation token is found, state is 


transitioned to "get length” state. 

5- When none of the above tokens are 


found, an exception is raised. 
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Name 


Purpose / Action 


Input / Transitions 


continued 

data 


element end 


Input: The data to parse 
Transitions : 

I- If child element is found, state is 
transitioned to ""element start” state. 

Builds the payload of the 

current element and binds it current element is 

to itself encountered, state is transitioned to 

""element end” state. 

3- If data cannot be parsed or when none 
of the above is found, an exception is 
raised. 

Input: End tag of the current element. 
Transitions : 

1- If a start tag for a new element is 
encountered, then state is transitioned to 
Pops the element from the element start state. 

stack and binds it to current 2- If end of the current stream is found, 
root element. state is transitioned to ""end” state. 

3- If another end tag of another element 
is found then state is transitioned to itself. 

4. When none of the above tokens are 
found, an exception is raised. 
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Name 

Purpose / Action 

Input / Transitions 

get length 

Reads the length of the 

variable length data. 

Input: The data type of the current 

attribute or data continuation token. 

Transitions : 

1- The length of the data is read and 

state is transitioned to '‘‘builtjyayload” 

state. 

E 

Error condition: declares the 

failure of the transition 

In any state errors can occur. The 

reasons for the error state are listed 

below. 

1 - Tag numbers cannot be found. 

2 - Data deserialization cannot be 

handled properly. 

3 - Invalid tokens are received. 

End 

Declares the success of the 

deserialization process. 

Input: End of the data stream 

Transitions : -- 


Table 3.5: Deseriali z ation Algorithm State Table 


The transition table for XML Deserialization is shown in Table 3.6. This table 
identifies the names, purposes, start and end states of the performed transitions in the 
CFSM. 


Name 

Purpose 

Start Sate 

End State 

incoming stream 

The start of the process is 

declared. 

— 

start 
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Name 


Purpose 


Start State 


End State 


startjtcig 

The start tag of an element is 

read. 

end_tag 

The end tag of the element is 

read. 

read_data 

Data is encountered 

attribute 

tokenj'ound 

Special token “1” is read 

from the stream 

child_elementJ'ound 

Another start tag is found 

during the processing 

current element. 

read attribute 

The token for the current 

attribute is read. 

new_attributeJ'ound 

A new attribute is found 

(token for the new attribute 

is read from the stream). 

attribute _payload 

Continuation of parsing the 

payload of the current 

attribute. 

read_length_token 

The length token for the 

variable length attribute 

payload is read. 


start 

element start 
element end 
element start 
element end 
continued data 
element start 

element start 

continued data 

attribute start 

build payload 

build payload 

get length 


element start 


element end 


continued data 

attribute start 


element start 


built payload 


attribute start 


build payload 


build payload 
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Name 

Purpose 

Start State 

End State 

continuation_token 

found 

A special token for payload 

continuation is found. 

build payload 

get length 

open_or_close 

element_tcig found 

Open or close tag for an 

element is read. 

built payload 

element start 

arrayjtype 

If data type of the current 

attribute is an array type, 

where the data type is 

looked up from the table. 

attribute start 

get length 

EOF 

End of stream is read. 

element end 

end 


Table 3.6: Deserialization Algorithm Transition Table 


G. DATA TYPES 

In XFSP 13 native data types [W3C Schema Part II] are implemented. These data 
types provide the foundation of data structures that XFSP can understand. The main point 
of implementing XFSP data types is pushing the serialization and deserialization of data 
into the classes where data is actually stored. 

These data objects are created when the text-based XML document is parsed or 
when a serialized stream is received at the user end. The UML diagram for implemented 
data types is shown in Figure 3.5. 

The data types can be divided into two main categories such as Complex Type 
and Simple Type. Complex Type provides name storage for the XML elements where 
they implement non-primitive type data structures. Simple Types are the objects where 
actual primitive or array type data is stored. These data types have the capability to store 
the data, serialize it into the given output stream, deserialize it from the received input 
stream and provide that data as text to the user. The implemented data types are shown 
below. The prefix XSD is used to distinguish these types from the primitive types used in 
the Java programming language. 
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• XSDByte 

• XSDUnsignedByte 

• XSDShort 

• XSDUnsignedShort 

• XSDInteger 

• XSDUnsignedInt 

• XSDLong 

• XSDFloat 

• XSDDouble 

• XSDBoolean 

• XSDString 

• XSDComment 

• SimpleTypeExtension 


In XFSP, these objects are bound to the XML tree during the tree generation 
process. These objects can represent primitive data structures as well as user defined 
complex data types. 


H. XFSP AND NPSNET-V 

XFSP is introduced as a run-time extensible application layer protocol into the 
NPSNET-V. As discussed before, NPSNET-V is a run-time extensible networked virtual 
environment architecture having both DIS and HLA capabilities to share information for 
participating users. The major advantage of using NPSNET-V to show the run-time 
extensibility of application protocols is its component based framework allowing 
components to be loaded at run-time to build the actual virtuahenvironment architecture. 
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NPSNET-V uses many well-known design patterns. The major ones that are used 
in XFSP components are Interface and Listener patterns. Both of these design patterns 
are highly used in the XFSP component in NPSNET-V architecture. 

The idea behind the Interface pattern is “... Keep a class that uses data and 
services provided by instances of other classes independent of those classes by having it 
access those instances through an interface” [Grand 98]. This pattern allows for a plug- 
and-play type of architecture within an application. “For example a certain application 
relies on a specific service to be provided, and that service can be provided by different 
service providers. All that the application interface needs to specify is a set of functions 
that any service provider must implement in order to provide the desired service. Any 
service provider that is to be used with that application must implement the function 
required by the interface in order for the applications to be able to use its services” 

[Salles 02]. 

The second pattern is the Fistener pattern, also commonly known as Observer 
pattern. This pattern lays the foundation for efficient notification of events occurring in 
one object to be transmitted to registered objects. 

In order to implement the XFSP component in NPSNET-V, two main controller 
modules, StandardXFSPController and XFSPExplosionManagerController are 
implemented. These modules can understand entity state and explosion packets defined 
by XMF-Schemas. 

These controllers define the semantics between the protocol syntax and 
application. They cause action of the received packets to be represented correctly in a 3D 
world when they are issued by the participating entities. Currently the semantics of fire 
and collision packets are not defined in the NPSNET-V framework, but XFSP can parse 
those packets and create the XMF documents from the received streams. 

UMF diagram of classes implemented to integrate XFSP and NPSNET-V is 
shown in Figure 3.20. 
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Figure 3.20: StandardXFSPController UML Diagram (Generated by [ESS]) 
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The following pictures show the run-time extensibility of the protocols in 
NPSNET-V. Figure 3.21 shows the start of the application with two ships communicating 
via multicast where they implement the same entity state protocol. Each ship is 
controlled by separate processes running on the same computer or separate hosts. In the 
presented pictures, therefore, one ship is local controller (master) and the other is ghosted 
copy (slave). 


_i *a 



Figure 3.21: Start of NPSNET-V Application 



Figure 3.22: Run-time Detonation Protocol Eoading 
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After the start of application, one of the clients loads a detonation entity 
associated with a detonation protocol schema. At the parsing process the entity that have 
loaded the schema sends a special message to the multicast group declaring the new 
protocol that it loaded. When the other entities receive the special message they parse the 
schema pointed to by the URL in the message and are then able to understand the 
detonation protocol syntax. Figure 3.22 shows one of the clients that received the 
message and parsed the schema pointed to in that message, resulting in execution of a 
detonation behavior. The format of the special message is shown below in Figure 3.23. 


<?xml version="1.0" encoding="UTF-8"?> 

<!-- Edited with XML Spy v4.3 by Ekrem Serin (NPS) -> 
<xs:schema xmins:xs="http://www.w3.org/2001/XMLSchema" 
eiementFormDefauit="quaiified"> 

<xs:eiement name="xfsp''> 

<xs:compiexType> 

<xs:sequence> 

<xs:eiement name="manager" type="managerType7> 
</xs:sequence> 

</xs:compiexType> 

</xs:eiement> 

<xs:compiexType name="managerType"> 

<xs:sequence> 

<xs:eiement name="entitySite" type="xs:short"/> 
<xs:eiement name="entityAppiication" type="xs:short"/> 
<xs:eiement name="entitylD" type="xs:short7> 
<xs:eiement name="schemaURL" type="xs:string"/> 
</xs:sequence> 

</xs:compiexType> 

</xs:schema> 


Figure 3.23: NPSNET-V Simulation Manager Type Packet Format 


L SUMMARY 

This chapter provides information about the implementation details of XFSP and 
an exemplar usagp in a Net-VE. Schema parsing, XME Serialization and XME 
Deserialization processes are covered in detail to address the research question and show 
how an XME document can be compressed and restored. 
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IV. BINARY X3D 


A. INTRODUCTION 

This chapter examines the design and implementation details of a binary X3D 
format for network streaming and file storage. 


B. OVERVIEW 

Extensible 3D (X3D) is an XML file format that describes a scene graph which is 
rendered as a 3D scene. X3D scene graph is a directed acyclic graph with nodes and 
edges. Nodes in the scene graph define the graphic and aural objects contained in the 
system, and the edges define the transformation hierarchy containing the spatial 
relationship of objects [Web3D]. X3D is the third-generation version of the ISO standard 
for The Virtual R-M-C-VRML97. 

Being an XML text file format makes X3D fairly heavyweight for network 
transmission as well as storage purposes. Text files generally require much more 
bandwidth than their binary equivalents. The compressed versions of text files offer an 
efficient way to send or receive data over the network as well as to store them locally. 
The idea of schema parsing, XML Serialization and XML Deserialization is used to 
compress the X3D files. The output file format is called ""Binary X3D” with . b3d or 
. b3 z file extensions depending on whether or not GZIP compression is further used. 

The following sections describe and analyze the binary X3D program by 
providing essential details on process flow. 


C. X3D-EDIT 

X3D-Edit is an authoring tool for X3D graphic scenes developed by using IBM’s 
Xeena, an XML-based tool-building application. It is a graphics file editor for X3D files 
that enables simple error-free editing, authoring and validation of X3D scene graph files 
[Brutzman X3D]. X3D scene graph files are translated to VRML97 syntax by using an 
XSLT stylesheet. The converted file format can be rendered by open-source browsers 
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(Xj3D) as well as commercial products; e.g., Internet Explorer by providing a plug-in. 
Figure 4.1 shows the X3D Edit interface for a typical "Teapot” example. 



Figure 4.1: Teapot.x3d File Example 


Figure 4.2 shows the output file rendered by using Cortona [Cortona 03] plug-in 
for Internet Explorer browser. The rendered file is in VRMF97 file format and generated 
by applying an XSFT stylesheet to the teapot.x3d file. The Figure 4.1 and Figure 4.2 are 
presented to show the how an XMF file that defines a 3D scene graph can be rendered. 
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Figure 4.2: Teapot.wri File Example 


D. BINARY X3D 

1. Binary X3D Program Interface 

Binary X3D program provides a compact way to store X3D files by exploiting the 
idea of schema parsing and XML Serialization described in previous chapter. In addition 
to XML Serialization, binary X3D program provides options to use GZIP streams to 
further compress the X3D files. The interface for the binary X3D program is shown in 
Figure 4.3. The implementation details and process flows are discussed at each option 
description. 



Figure 4.3: BinaryX3D Program Interface 
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The option “-c” is used to compress the X3D file to a binary X3D file. The 
output file extension is considered as . b3d which stands for binary X3D. 
The process for this operation is shown in Figure 4.4. The X3D file is 
provided as parameter to the Serializer program and compressed by using 
X3D Schema. 


X3D File 



X3D 

Schema 

Binarv X3D 

XFSP 

Serializer 

file (. b 3 d) 



Figure 4.4: Binary X3D File Generation 


The option “-d” is used to decompress binary X3D file format. The 
process for this operation is shown in Figure 4.5. The . b3d (Binary X3D) 
file is provided as a parameter to the Deserializer and decompressed by 
using X3D Schema. 


X3D 

Schema 


B3D File 


XFSP 

. x3d File 

Deserializer 



Figure 4.5: . x3d File Generation from . b3d File 


The option “-cz” is used to compress the X3D file by using Serializer 
program and GZIP streams. The output file format is considered as B3Z 
which stands for gzipped binary X3D. The process for this operation is 
shown in Figure 4.6. The X3D file is provided as a parameter to the 
Serializer program where it is serialized using X3D Schema and 
compressed using GZIP compression. 
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Figure 4.6: . b3 z File Generation (Gzipped Binary X3D) 


The option “-dz” is used to decompress gzipped binary X3D (. b3 z) file 
back to the . x 3 d file format. The process for this operation is shown in 
Figure 4.7. The . b3 z file is provided as a parameter to the GZIP stream 
and decompressed. The decompressed file (. b 3 d) is provided to 
Deserializer program and converted back to the . x3d file by using X3D 
Schema. 

X3D 

I Schema 


.b3z File 

GZIP 

.b3d 

XFSP 

. x3d 


Decompression 


Deserializer 



Figure 4.7: . x 3 d File Generation from . b 3 z File 


The option “-dr” is used to decompress binary X3D (. b3d) files and 
render them. To render . b 3 d file format an XSLT stylesheet is applied to 
the decompressed B3D (. x3d) file and transformed to VRML97 file 
format. The VRML97 file format is loaded into a VRML or X3D browser 
(e.g. Xj3D). The complete process flow for this operation is shown in 
Figure 4.8. 
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Figure 4.8 : Rendering . b3d File Format 


The option “-dzr” is used to decompress . b 3 z files and render them by 
using a browser. To render . b3 z file format, the input file is 
decompressed by gzip stream and converted to a . b 3 d file format. The 
.b3d file is converted to . x3d file by using the XFSP Deserializer 
program. An XSLT stylesheet is applied to the X3D file and transformed 
to VRML97 file format. The VRML97 file is rendered by using Xj3D 
browser. The complete process flow for this operation is shown in 
Figure 4.9. 



Figure 4.9: Rendering . b3z File Format 
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2. Analysis 

To test the designed program, a eornmon example 'Teapot” is used. The 
teapot.xSd file eontains 14994 integer numbers that define the eoordinate indiees, and 
5916 floating point numbers that represent the eoordinates of vertiees in 3D. 
Furthermore, the Teapot file ineludes various elements and attributes that define the 
material and eolor properties of the objeet. The rendered teapot is shown in Figure 4.2. 

The following eharts shows the data eolleeted by using different file formats and 
eompression sehemes. In Figure 4.10 the x-values represent the file format, and y-values 
represent the size of the file in Kbytes. The file formats used for eomparison are 
deseribed below. 

- x3d : X3D File Format 

- wrl : VRML97 File Format 

- b3d : Binary X3D File Format 

- zip_x3d : X3D File Compressed by WinZip Program 

- zip_wrl : VRML97 File Format Compressed by WinZip Program 

- b3z : X3D File Compressed by Serializer using GZIP Streams 



Figure 4.10: File Format Comparison for Teapot Exemplar 
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Figure 4.11 represents the storage and bandwidth gained by using different file 
formats. The base for percentage calculation is set as the teapot.xSd file. The B3Z file 
format provides 78% bandwidth saving over the regular X3D file format. Furthermore, 
B3Z file format provides 12% saving over the compressed WRL file format commonly 
known as WRZ file format. The teapot.xSd example contains much more data than the 
element and attributes names. For an exemplar including many elements and attributes, 
the storage savings will increase due to the Serializer program compression. In that case, 
attribute and element names will need more storage and the Serializer program will work 
more effectively to compress the X3D file. 



Figure 4.11: File Format Percentage Saving for Teapot Exemplar 


The properly reconstructed and rendered teapot.bSz file is shown in Figure 4.12. 
The total amount of time for decompression, stylesheet transformation and rendering is 
measured as 5 seconds. The experiment was conducted on a Dell Inspiron 8200 Laptop 
with P4 1.6GHz CPU, 512 MByte RAM and 64 MByte GeForce-4 graphics card. 
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Figure 4.12: Rendered teapot.bSz File 


E. SUMMARY 

This chapter provides information about the implementation details of binary 
X3D file formats (.b3d and .b3z). .b3d file format offers 34% bandwidth gains over 
regular X3D file format; B3Z file format offers 78% bandwidth gains for Teapot 
exemplar. Additionally, .b3z file format provides 12% bandwidth gains over zipped 
VRML97 file format. These compression improvements from using XML are consistent 
with other results. The implemented program provides an effective way to use network 
bandwidth as well as local storage capacity by using XML Serialization and GZIP stream 
compressions. 
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V. 


PROTOCOL DATAGRAM UNIT (PDU) FARM 


A. INTRODUCTION 

This chapter examines the design and implementation details of Pdu Server, Pdu 
Capture md Network Analyzer pxogxdms. 

B. OVERVIEW 

In order to test the designed Net-VE for 24 hours a day and 7 days a week, three 
main programs, Pdu Server, Pdu Capture and Network Analyzer are implemented. As 
their names imply, these programs are used to send and receive packets as well as to 
monitor the network state between end points. 

In the monitoring process, previously described metrics such as latency, drop-rate 
and jitter are collected and stored in a file to help users draw conclusions about the 
current state of the network between the end points. 

Protocol Datagram Unit (PDU) Farm is defined as the collection of computers 
where previously recorded or run-time generated packets are continuously transmitted 
over the network. In order to establish a PDU Farm, implemented programs are loaded to 
four different computers and run continuously. Current implementation of PDU Farm 
needs previously recorded packets to execute its task. The main point is mimicking a 
previously played scenario to draw conclusions about different metrics such as network 
state, rendering performance or memory usage for Net-VEs. 

In the benchmark tests the total bandwidth of four computers is measured as 1.6 
Mbps. With this bandwidth 300 different entities with one packet per second send rate 
can be represented in highest resolution XFSP (670 bytes) packet format. 

The implementation details of PDU Farm are covered in the following sections. In 
order to present the design scheme of PDU Farm, a UMF diagram is provided in 
Figure 5.1. The UMF diagram presents the implemented Java classes. 
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Figure 5.1: PDU Farm UML Diagram (Generated by [ESS]) 
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c. 


PDU SERVER 


The Pdu Server program is used to send previously recorded packets to the end- 
users via unicast or multicast transport. These previously recorded packets are stored in a 
file where they are encapsulated by a special wrapper. This wrapper is used to determine 
the capture time and capture order of the received packet. 

In order to simulate the previously recorded scenario precisely, the captured 
packets are sent at the rate and in the order of their capture intervals. These time intervals 
define the send time of the captured packet. 

Starting the Pdu Server is done by a batch (DOS) or bash (Linux) file. This file 
uses an XML file to define initialization parameters of the server. An example 
initialization file is shown in Figure 5.2. 


<?xml version="L0" encoding="UTF-8"?> 

<!-- Edited with XML Spy v4.3 by Ekrem Serin (NFS) --> 

<System xmlns:xsf 'http://www.w3.org/2001/XMLSchema-instance'!> 
<!-- Time pattern is mm.dd.yyyy hh:mm:ss--> 

<StartTime>03.29.2003 09:34:00</StartTime> 
<EndTime>03.29.2003 1 l:35:00</EndTime> 

<Eoop>true </Eoop> 

<SocketIP>225.23.93.25</SocketIP> 

<Port>6 1 000</Port> 

<URL> file://c :/xfsp/nps .pdu</URE> 

</System> 


Eigure 5.2: Pdu Server Initialization Parameters 


Start and end time fields in Eigure 5.2 define the start and end time of the 
application. In the given example the server will start running at 29^*^ of March 2003 at 
9:34:00 am. and will stop at 29'*’ of March 2003 at 11:35:00 am. Between the actual start 
time and the start of the application, the server will enter to sleep state. At the end of the 
sleep state the server will wake up and will start sending previously recorded packets. 

The Eoop field in this initialization document defines whether the server will use 
the same file where previously recorded packets are stored continuously between its start 

and end. The Eoop true means that the server is going to use the same file continuously 
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during its operation. When the server reaches the end of the file it will restart sending the 
packets from the top of the file. 

The SocketIP field determines the IP address that the server will use to send the 
recorded packets. The server is capable of sending both unicast as well as multicast 
packets. If the provided IP is in the multicast IP address range 
(224.0.0.0 - 239.255.255.255) the server will open a multicast socket and join that 
address group. In the unicast IP case, the server will open a unicast socket and send the 
packets to that IP address. 

The Port field is used to define the port number to send the packets. A port 
number is an integer number between 1- 65535 and differentiates the applications 
running on the same computer with the same IP. It can be considered as the multiplexer 
where the operating system uses it to hand the incoming data to the correct application. 

The URL (Uniform Resource Locator) field determines the location of the file 
that will be used for sending the packets. As mentioned before, that file stores the 
previously recorded packets. 

When the initialization parameters are provided with the XML document, the 
server uses these parameters to set its internal attributes. After setting internal attributes, 
the server sends the recorded packets to a unicast user or to a multicast group. The output 
of the PDU Server program is shown in Figure 5.3. In order to run the server remotely on 
computers with Linux Operating System (OS), no graphical user interface is used. Text- 
based command-line startup simplifies remote invocation. 
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Figure 5.3 : Output of PDU Server Program 


D. PDU CAPTURER 

The Pdu Capture program is used to capture the packets generated by other users 
and store them in a file for the future use to regenerate the previously played scenario. 

The server listens to a unicast or multicast socket and receives the packets. At each 
packet receive interval it wraps the packet payload by a special wrapper where it puts the 
length and receive time of the received packet in that wrapper. 

Starting of Pdu Capture program is similar to Pdu Server where a batch (DOS) or 
bash (Linux) file is used. This file uses an XML file to define initialization parameters of 
the capturer program. An example initialization file is shown in Figure 5.4. 

Start and end time fields in Figure 5.3 are similar to PDU Server program. These 
fields define the start and end time of the application. In the given example the server will 
start running at 29^^ of March 2003 at 4:55:00 pm. and will stop at 29'^ of March 2003 at 
6:15:00 pm. Between the actual start time and the start of the application, the capturer 
will enter to sleep state. At the end of the sleep state, the capturer will wake up and will 
start capturing the packets. 


83 



<Systein xmlns:xsi= "http://www.w3.org/2001/XMLSchema-instance"> 
<!— Edited with XML Spy v4.3 by Ekrem Serin (NFS) —> 

<!-- Time pattern is mm.dd.yyyy hh:mm:ss--> 

<S tartTime>03 .29.2003 16:55: 00</StartT ime> 
<EndTime>03.29.2002 18: 15:00</EndTime> 

<SocketIP> 127.0.0. l</SocketIP> 

<Port>6 1 000</Port> 

<HeaderPileURL>file://c:/xfsp/PileHeader.xml</HeaderPileURL> 

</Svstem> 


Eigure 5.4: Pdu Capture Program Initialization Parameters 


The SocketIP field determines the IP address that the Pdu Capture program will 
use to receive the packets. The server is capable of receiving both unicast as well as 
multicast packets. If the provided IP is in the multicast IP address range 
(224.0.0.0 - 239.255.255.255) the capturer will open multicast socket and join that 
address group. In the unicast IP case, the capturer will open a unicast socket and receive 
the packets on that IP. If the provided unicast IP address is not the local-host or not the IP 
address of one of its network interfaces then the capturer will not be able to receive any 
incoming packets. 

The Port field is used to define the port number to receive the packets. A detailed 
description port number is provided in PDU Server program section. 

The HeaderPileURL field determines the location of the header file, an XML file, 
which is copied to the top of the file where the captured packets are stored. The reason 
for using an approach l ik e this is to be able to see the content of the binary file in which 
the captured packets are stored. An example of the header file is shown in Eigure 5.5. 
When the recorded PDU file is opened by notepad or any text file viewer the XML file in 
Eigure 5.5 will be on top of that file where it describes the content of the opened file. The 
captured packets will follow this XML-text in binary format where they will not be 
correctly interpreted by the text file viewer used. This provides the user the flexibility of 
seeing at least the content of a binary file with a text file viewer. 
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<?xml version="1.0" encoding="UTF-8"?> 

<!— Edited with XML Spy v4.3 by Ekrem Serin (NFS) --> 

<FileHeader xmlns:xsf 'http://www.w3.org/2001/XMLSchema-instance"> 
<T ype>XF SP</T y pe> 

<Description>NPS Ship for IITSEC-Demo</Description> 
<RecordedBy> Ekrem Serin</RecordedBy> 

<Date>l 1 .29.2002</Date> 

<URL>file://c:/xfsp/xfspNPS.pdiK/URL> 

</EileHeader> 


Eigure 5.5: A Eile Header for Recorded PDU Eile 


The output of the PDU Capturer program is shown in Eigure 5.6. In this output, 
the program prints the initialization parameters and starts listening for the incoming 
packets. 



:\xfsp>runPDUCapturer 


C:\xfsp>cd classes 

C:\xfsp\classes>jaua org.npsnet.xfsp.pduseruer.PDUCapturer file://c:/xfsp/Captur 
e .xnl 

Initialization Parameters 


Address : 127.0.0.1 
Port : 61000 

Start Tine : Fri Nou 29 16:55:00 PSI 2002 
End line : Fri Noo 29 18:15:00 PSI 2002 
URL : file:///c:/xfsp/xfspGttUl.pdu 


Eigure 5.6: Output of Pdu Capture Program 


E. NETWORK ANALYZER 

The NetworkAnalyzer program is used to collect the previously decided metrics 
such as latency, drop-rate and jitter between two end-points. With this feature users are 
able to draw conclusions about the current state of the network. These metrics also 
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provide information about network congestion and can be used to automatically tune the 
designed Net-VE. The tuning process includes send-rate change and packet resolution 
switching to enhance the performance. The automatic tuning is out of the scope of this 
thesis and is not implemented. The implementation purpose of the NetworkAnalyzer is 
network monitoring from an application-layer perspective. 

The start of the application is very similar to Pdu Server and Pdu Capture 
program which is done by a batch (DOS) or bash (Linux) file using an initialization file 
written in XML. The sample initialization file is shown in Ligure 5.7. 


<?xml version="1.0" encoding="UTL-8"?> 

<!-- Edited with XML Spy v4.3 by Ekrem Serin (NFS) --> 

<System xmlns:xsf 'http://www.w3.org/2001/XMLSchema-instance"> 
<DestinationAddress>129.174.65.60</DestinationAddress> 
<DestinationPort>9080</DestinationPort> 
<ReceivePort>9080</ReceivePort> 
<SendRateKbps>10</SendRateKbps> 
<PayloadInBytes>500</PayloadInBytes> 
<NumberOfPackets>2000</NumberOfPackets> 
<OutputPileURL>file://c:/xfsp/AnalyzeResults.txt</OutputPileURL> 
</System> 


Ligure 5.7: NetworkAnalyzer Initialization Lile (Sender) 


<?xml version="1.0" encoding="UTL-8"?> 

<!— Edited with XML Spy v4.3 by Ekrem Serin (NFS) --> 

<System xmlns:xsf 'http://www.w3.org/2001/XMLSchema-instance"> 
<DestinationAddress>13 1.120.7. l</DestinationAddress> 
<DestinationPort>9080</DestinationPort> 
<ReceivePort>9080</ReceivePort> 

</System> 


Ligure 5.8: NetworkAnalyzer Initialization Lile (Receiver) 

In order to collect previously mentioned metrics, a Listener must be up and 
running at the other end. Listener receives the packets and replays them back to the 
sender. A sample initialization file for listener is shown in Ligure4.8. 

The sender keeps track of each packet that it sends. When the packet is issued by 
the sender, current time for that packet is stored; at the time that sender ^ts the replayed 
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packet back, it updates the receive time for the packet. Packets that are not received back 
by the sender are considered as dropped. 

At the end of the process, packets sent and received are analyzed to calculate the 
latency, drop-rate and jitter. The latency is calculated by dividing RTT (Round Trip 
Time) by two, the drop-rate is determined by keeping a counter for the packets that are 
not received and jitter is obtained by measuring variations between delays. 

The fields of the initialization file in Figure 5.7 are self-descriptive. The send-rate 
field is slightly important from the network programmer perspective. The send-rate 
depends on the CPU cycle that the application runs on and the buffer allocation by the OS 
(Operating System) to the current process. In order to set the send-rate the sender is 
forced to sleep for the calculated sleep time which is measured by sending test packets to 
the local host. In order to test the accuracy of the designed program tests are conducted 
on a computer with P4 I.6GHz processor and 512 MB RAM (Random Access Memory). 
The conducted tests showed that send-rates up-to 400Kbps are accurately achieved by the 
designed program, and rates higher than that rate cannot be achieved due to OS system 
calls for sleep threads. 

In network analyzing, there are three major points that the network analysis must 
consider. First, the current architecture of the Internet is a packet-switched network where 
packets can be routed via different routes resulting in out of order reception. Second, 
drops may occur at different places such as during transit from sender to receiver, at the 
receiver due to high send-rate and buffer limitation and during the transit from receiver to 
the sender. Third is that time-measurement in the Java programming language cannot be 
accurate for the values less than 10 milliseconds. The Java program cannot necessarily 
distinguish such precise differences due to the accuracy of various operating system calls. 
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F. SUMMARY 

This chapter provides information about the implementation details of Pdu 
Server, Pdu Capture and NetworkAnalyzer programs. The implemented programs are 
described in detail to show the design of a simple PDU Farm. The PDU Farm is able to 
send and receive unicast as well as multicast messages. With this framework previously 
recorded scenarios can be replayed and analyzed. Another possible use of this work is 
simulating off-site entities without the need of rendering. 
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VI. EXPERIMENTS, DATA COLLECTION AND ANALYSIS 


A. INTRODUCTION 

This chapter examines the results and collected metrics from the conducted 
experiments. 

B. OVERVIEW 

In order to test the speed of XML Serialization program and collect the network 
metrics described previously, two sets of experiments were conducted. In the first set, the 
speed of XML Serialization program is tested by continuously generating serialized XML 
documents and sending them to the local host. In this set, the number of serialized 
documents that are sent and the number received are tracked. Additionally, the duration 
for XML Serialization is measured. 

In the second set of experiments, latency, jitter and drop-rate were measured 
between George Mason University (GMU) (Fairfax, Virginia) and Monterey, California 
by using commercial Internet Service Providers (ISPs) on V.98 modem as well as on 
Ethernet. The Naval Postgraduate School (NPS) network infrastructure is not used for the 
initial set of experiments due to firewall problems described in the following sections. 

C. XML SERIALIZATION PROGRAM 

To test the speed of XML Serialization program, XML Serializer is programmed 
to continuously generate serialized XML documents. These binary XML documents 
(serialized) are sent to the local host listening on a specified UDP port. 

The experiments are condueted on a machine whose properties are listed below. 

In the following list, the protocol and the buffer sizes are also specified. 

Brand : Dell Inspiron 8200 Laptop 

CPU and Memory : P4 1.6 GHz, 512 MByte 

Transport Protoeol: UDP 

Send Buffer Size : 8192 Bytes 

Receive Buffer Size : 8192 Bytes 

XFSP Entity State PDU Size : 670 Bytes 
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This experiment shows the rate of binary XML document generation and the drop 
rate on UDP socket with 8192 Bytes receive buffer size. In this test the documents are 
generated continuously and are not regulated for send rate resulting in burst sending. The 
metrics collected for this set of experiment are shown in Table 6.1. Table 6.1 specifies the 
number of serialized XML documents that are sent and received as well as the total 
duration for serializing them. 


Sent 

Received 

Duration 

(secs) 

Binary XMF 

Documents / Sec 

10 

10 

0.2 

50 

100 

100 

0.47 

212 

200 

200 

0.89 

224 

300 

300 

1.18 

254 

400 

400 

1.47 

272 

500 

425 

1.73 

289 

600 

524 

1.97 

304 

700 

468 

2.12 

330 

800 

409 

2.39 

334 

900 

474 

2.67 

337 

1000 

558 

2.95 

338 

5000 

1987 

12.83 

389 

10000 

3991 

25.14 

397 

20000 

7775 

48.27 

414 


Table 6.1: XML Serialization Program Experiment 
As seen from Table 6.1, the Serializer program reaches its maximum limit at 
20000 serialized XML document row and starts to generate the XML documents at a rate 
-410 documents / sec. The serialized XML documents were XFSP Entity State PDUs 
that occupied 670 Bytes in memory. The behavior of reaching its maximum limit is 
shown in Figure 6.1. Figure 6.1 reveals that XMF Serializer program cannot generate 
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XFSP Entity State PDUs faster than -410 documents /sec which is sufficient for fairly 
sophisticated Net-VEs. 



Eigure 6.2 shows the analysis of drop-rate for local host transmission. The drops 
in local host transmission occur due to buffer and CPU cycle limitations. In socket 
operations, an Operating System (OS) assigns a buffer for sending and receiving 
processes to each socket opened. Eor example, the default buffer value that Windows 
uses for UDP sockets is 8192 Bytes. When the program receives at a rate higher that it 
can handle, the received packets will be dropped until enough space is available in the 
buffer. As seen from Eigure 6.2, the drop-rate on UDP socket with 8192 Bytes receive 
buffer is increasing as the send-rate increases. 
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Figure 6.2: Drop Rates for Local Host Transmission 

Figure 6.2 reveals that after reaching certain send-rate some packets will be 
ignored by the receiver. 

D. NETWORK METRICS 

In order to design rich and well-managed Net-VEs, application implementers 
need to consider basic metrics such as latency, drop-rate and jitter over different network 
topologies. These metrics help designers to manage their transmission and receive rates 
as well as the performance of the simulation that they implement. The effects of latency, 
drop-rate and jitter on a Net-VE are described previously. A Net-VE with poor network 
management will distract users and reduce their sense of immersion. 

Two sets of experiments are conducted to measure the network metrics. Eor both 
experiments, the receive point was George Mason University (Eairfax, Virginia). In the 
first set of experiments, a commercial ISP is used by connecting via PPP (Point-to-Point 
Protocol) over V.98 voice modem. In the second set of experiments another commercial 
ISP is used by connecting via Ethernet over Tl. The results achieved from the conducted 
experiments are presented and analyzed in the following sections. 


92 















1. V.98 Voice Modem 


To test the V.98 voice modem transmission, two sets of experiments are 
conducted. At each experiment the send rate is changed and previously described metrics 
are collected. In the first experiment 2000 packets with 500 Bytes payload are sent at a 
rate of 10 Kbps. The collected metrics for this experiment are shown in Table 6.2. 


Send Rate 

Total Packets 

Drop Rate 

Average Latency 

Average Jitter 


Sent 

(%) 

(msecs) 

(msecs) 

10 Kbps 

2000 

2.0 

146.6 

2.54 


Table 6.2: Metrics for 10Kbps Transmission on V.98 Modem 


The measured latencies and jitter for this set of experiment are represented in 
Figure 6.3. and Figure 6.4 respectively. 
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Figure 6.3: Cross-USA Latency in 10Kbps Send Rate on V.98 Voice Modem 
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Figure 6.4: Cross-USA Jitter in 10Kbps Send Rate on V.98 Voice Modem 

In the second set of experiments, 4000 packets with payload 500 bytes are sent at 
50 Kbps rate. Drop-rate is measured as 1.18%. The average latency and jitter values are 
shown in Table 6.4. 


Send Rate 

Total Packets 

Drop Rate 

Average Latency 

Average Jitter 


Sent 

(%) 

(msecs) 

(msecs) 

50 Kbps 

4000 

1.18 

158.32 

15.62 


Table 6.3 : Metrics for 50Kbps Transmission on V.98 Modem 

The measured latencies and pure jitters for this set of experiment are represented 
in Figure 6.5. and Figure 6.6, respectively. 
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Figure 6.5: Cross-USA Latency in 50Kbps Send Rate on V.98 Voice Modem 
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Figure 6.6: Cross-USA Jitter in 50Kbps Send Rate on V.98 Voice Modem 
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The experiments conducted on V.98 voice modem using PPP ISP connection 
revealed that average delay between Monterey, California and Fairfax, Virginia is over 
140 milliseconds for a voice modem transmission. It also shows that the delay is not a 
constant process and can change due to network conditions. The Net-VE designer can use 
these metrics while designing their Net-VE to control the transmission rate. 


2. Wide-Area Network (Tl) 

To test the Ethernet transmission, three sets of experiments are conducted. At 
each experiment, the send rate is changed and previously described metrics are collected. 
In the first experiment 2000 packets with 500 bytes payload are transmitted at a 10 Kbps 
send-rate. In this set, the drop-rate is measured as 1.13%. The collected metrics for this 
experiment are represented in Table 6.4. 


Send Rate 

Total Packets 

Drop Rate 

Average Eatency 

Average Jitter 


Sent 

(%) 

(msecs) 

(msecs) 

10 Kbps 

2000 

1.13 

51.9 

2.84 


Table 6.4: Metrics for 10Kbps Transmission on Tl 

The measured latencies and jitter for this set of experiment are represented in 
Eigure 6.7. and Eigure 6.8, respectively. 
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Figure 6.7: Latency in 10Kbps Send Rate on T1 



Figure 6.8: Jitter in 10Kbps Send Rate on T1 

In the second set, 5000 packets with payload 500 bytes are sent at 100 Kbps rate. 
In this experiment the drop-rate is measured as 3.8%. The average latency and jitter 
values are shown in Table 6.5. 
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Send Rate 

Total Packets 

Drop Rate 

Average Fatency 

Average Jitter 


Sent 

(%) 

(msecs) 

(msecs) 

100 Kbps 

5000 

3.8 

64.4 

2.5 


Table 6.5: Metrics for 100Kbps Transmission on Ethernet 


The measured latencies and jitter for this set of experiment are represented in 
Figure 6.9. and Figure 6.10, respectively. 


100 Kbps Send Rate (Latency) 



1 330 659 988 1317 1646 1975 2304 2633 2962 3291 3620 3949 4278 4607 


Packet Nnmber 


Figure 6.9: Fatency in 100Kbps Send Rate on T1 



Figure 6.10: Jitter in 100Kbps Send Rate on T1 
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In the last set, 10000 packets with payload 500 bytes are sent at 400 Kbps rate. In 
this experiment the drop-rate is measured as 4.76%. The average latency and jitter values 
are shown in Table 6.6. 


Send Rate 

Total Packets 

Drop Rate 

Average Eatency 

Average Jitter 


Sent 

(%) 

(msecs) 

(msecs) 

400 Kbps 

10000 

4.76 

217.8 

0.4 


Table 6.6: Metrics for 400Kbps Transmission on Ethernet 


The measured latencies and jitter for this set of experiment are represented in 
Figure 6.11. and Figure 6.12 respectively. The latency began at values similar to earlier 
runs, but increased over time. The most probable cause of this is increasing queue size in 
routers. At low data rates the queues stay relatively empty. As the data rate crosses the 
queue service threshold the queue grows to its capacity and starts dropping the received 
packets. There are various schemes for handling long queue sizes (e.g. dropping packets) 
in routers. Probably the most popular is tail-drop. In this scheme, the packet queue size 
grows until there is no room in the queue, and the arriving packets are simply dropped. 
Another popular dropping scheme is Random Early Drop (RED). In that scheme, when 
the queue size reaches some size smaller than its full capacity, the packets to be dropped 
are selected randomly. The probability of drop for both schemes increases as the queue 
size increases to its capacity. 

Another logical explanation for exponential increase in latency is packets to be 
delivered using different routes. When the link between two hops becomes congested, the 
routers can choose the packets to follow different hops resulting in different latency 
values for different packets. The calculation of using different route will also put some 
latency over the packets during their journey from source to destination. 
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Figure 6.11: Latency in 400Kbps Send Rate on T1 (Day-1) 



400 Kbps Send Rate (Jitter) 
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Figure 6.12: Jitter in 400Kbps Send Rate on T1 

The experiments conducted to analyze the exponential increase behavior gave 
similar results one on different days, Figure 6.13 and Figure 6.14. The routes from 
George Mason University to Moves Inst itute . org are also presented to track the 
problem. This type of behavior can be caused by any of the nodes listed in Figure 6.15. 
The traceroute packets followed the same path presented in Figure 6.15 before and after 
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high rate transmission. This data reveals that the probable cause of latency problem is 
drops occurring in routers. 



Figure 6.13: Latency in 400Kbps Send Rate on T1 (Day -2) 
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Figure 6.14: Latency in 400Kbps Send Rate on T1 (Day -3) 
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[netlab] # traceroute movesinstitute.org 

1 netlab (129.174.65.1) 1.174 ms 0.793 ms 0.741ms 

2 129.174.249.129(129.174.249.129) 0.871 ms 0.735 ms 0.694 ms 

3 129.174.248.233 (129.174.248.233) 1.115 ms 1.176 ms 1.109 ms 

4 129.174.247.118(129.174.247.118) 0.855 ms 0.605 ms 0.861ms 

5 WTNl-GeorgeMasonUFairfax.networkvirginia.net (65.162.90.5) 6.902 ms 6.662 
ms 5.833 ms 

6 65.162.89.38 (65.162.89.38) 10.842 ms 10.816 ms 10.539 ms 

7 sl-gw20-rly-2-2.sprintlink.net (160.81.255.1) 11.820 ms 11.909 ms 11.072 
ms 

8 sl-bb23-rly-3-2.sprintlink.net (144.232.14.45) 142.828 ms 205.470 ms 244. 

164 ms 

9 sl-bb21-pen-12-0.sprintlink.net (144.232.20.33) 21.815 ms 17.643 ms 13.12 
1 ms 

10 sl-bb20-pen-15-0.sprintlink.net (144.232.16.33) 17.500 ms 17.448 ms 13.96 
7 ms 

11 sl-bb20-stk-10-0.sprintlink.net (144.232.18.46) 79.529 ms 76.489 ms * 

12 sl-gw25-stk-9-0.sprintlink.net (144.232.4.218) 73.191 ms 71.910 ms 73.974 
ms 

13 sl-swb-57-0.sprintlink.net (144.223.59.86) 80.435 ms 81.463 ms 78.775 ms 

14 dedl-fa5-l-0.mtry01.pbi.net (206.171.158.133) 83.213 ms 81.779 ms 77.889 
ms 

15 Naval-Post-Graduate-School-505769.cust-rtr.pacbell.net (209.232.139.54) 86. 

757 ms 81.758 ms 80.937 ms 

16 63.205.26.77 (63.205.26.77) 88.010 ms 79.443 ms 82.471 ms 


Figure 6.15: Traceroute From gmu . edu To Moves Institute . org 


E. NFS FIREWALL PROBLEM 

Experiments using Naval Postgraduate School network backbone were 
infrequently conducted due to firewall problems. To find the reasons of firewall problem, 
the traceroute program is used. This program shows all the nodes that traceroute packets 
hit during their journey from source to destination. 

When the computer behind Naval Postgraduate School firewall was 
"Hracerouted”, firewall acted as a proxy and sent Internet Control Message Protocol 
(ICMP) packets to the traceroute initiator. In this case, the traceroute initiator assumed 
that the packets could be delivered to the computer behind the firewall. Unfortunately, 
when the experiments were attempted, the firewall intercepted every packet destined for 
the computer behind it, and did not forward them. Although the first proxy behavior is 
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consistent with firewalls that try to hide its internal topology, the second behavior is not 
consistent and should be resolved. Firewall adjustments and further experiments need to 
continue. 


F. SUMMARY 

This chapter summarizes the data collected in conducted experiments. For data 
collection two main sets of experiments are conducted. In the first set the speed of XML 
Serializer program is measured, and in the second, network metrics are measured by 
using V.98 voice modem and Ethernet transmission. Furthermore, the results achieved 
are represented in 2D graphs. 

This chapter also presents the usage of Network Analyzer program. This program 
can be used as proxy to track the changes in the latency where the changes can serve as 
basis to find the maximum capacity of the link. Additionally, the capacity of the link can 
be used to better manage the network transmissions resulting in richer Net-VEs. 
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VII. CONCLUSIONS AND FUTURE WORK 


A. CONCLUSION 

1. Application Layer Protocol Extensibility 

Application layer protocols can be extended at run-time by using a protocol 
definition language. The run-time extensibility of the application layer protocols provides 
a way to optimize the bandwidth usage and to meet the needs of different users at 
different fidelity levels. 

Extensibility in Net-VE architectures is essential because it is clear that networks 
will continue to evolve, and a closed system which cannot be changed would be obsolete 
as the networking technology evolves. 

In this framework, XME Schema is used and considered as a good candidate to be 
protocol definition language. XME Schema can well describe the application protocol 
syntax with its internal as well as user-defined data structures. In order to parse the 
protocol definition document written in XME Schema, a schema parser is implemented. 


2. XML Serialization and XML Deserialization 

XML Serialization provides a compact way to send and receive XML documents 
over the network. Currently most of XML documents use UTE-8 encoding which 
corresponds to the 8-bit ASCII encoding. With this scheme each alphabetical character 
and number is represented by eight bits. Instead of using 8 bits for each character, the 
notion "“’agreement” is exploited and element and attribute names are replaced by binary 
short tags. Eurthermore, the data marked-up by elements and attributes are serialized to 
binary form resulting in compact XML. 

With the implemented algorithm XML documents are compressed without using 
any binary compression algorithms. 

Driving factors of avoiding binary compression algorithms are simplicity of 
implementation, computational speed performance and skipping bitwise operations by 
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providing reimplementability and generality. Further elaborations can complicate the 
protocol beyond the comprehensibility except for information encoding experts. 

The compressed XML document is called as binary XML and decompressed by 
the XML Deserializer. The result of the decompression is the text XML document 
provided to the XML Serializer. 

With XML Serializer and XML Deserializer XML documents are sent in a more 
compact way over the network providing bandwidth and time saving. 


3. PDU Farm and Network Monitoring 

In this thesis a simple PDU Farm and Network Monitoring is implemented. PDU 
Farms let users to test the designed Net-VE for 24 hours a day and 7 days a week. 
Furthermore, they provide a way to mimic the previously played scenarios to draw 
tactical as well as technical conclusions. 

The technical conclusions derived from the played Net-VE simulation include the 
metrics for the bandwidth consumption, rendering performance and memory usage. The 
recorded scenario can also be replayed multiple times to accurately measure these metrics 
resulting in enhancing the design of Net-VE. 

The network monitoring program measures the current state of the network and 
provides information about network congestion, latency, drop-rate and jitter. These 
metrics are highly used by network programmers and can provide a fundamental for 
tuning purposes mentioned in the recommendations for future work section. 
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B. RECOMMENDATIONS FOR FUTURE WORK 
1. General XMU Serializer / Deserializer 


XML Serialization and Deserialization can be enhanced to compress and 
decompress any XML document defined by any XML Schema. Currently, XFSP is an 
ongoing project and will be enhanced to base the generation of binary XML documents. 
The recommended process for this enhancement includes; 

• A schema validator implementation where it validates the provided 
schema. 

• Namespace handling 

This work needs to be continued as a general purpose XML compressor for both 
network and file streams. 


2. Monitoring Agents 

An agent is a computer system that is situated in some environment and that is 
capable of autonomous action in this environment in order to meet is design objectives 
[Wooldridge 01]. To automatically tune the networking and change the application layer 
protocol in a Net-VE, the software agents can be used. 

The network monitoring process can be implemented as an autonomous system 
and incorporated into the designed Net-VE system. These autonomous agents can work 
together and create a complex adaptive system, where that system can change the 
application layer protocol by using environmental information such as delay, drop-rate 
and jitter. 

The complex adaptive system can optimize the network utilization and provide a 
better managed network on which rich and responsive large-scale networked virtual 
environments can be implemented. 
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APPENDIX A. DIS SCHEMA 


<?xml version="1.0" encoding="UTF-8"?> 

<!— Edited with XML Spy v4.3 by Ekrem Serin (NFS) —> 

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema " 
elementEormDefault="qualified"> 

<xs:element name = "dis"> 

<xs:complexType > 

<xs:choice> 

<xs:element name="espdu" type="espduType "/> 

<xs:element name="collisionpdu" type="collisionpduType "/> 

<xs:element name="firepdu" type="firepduType"/> 

<xs:element name="detonationpdu" type="detonationpduType "/> 
</xs:choice> 

</xs : complexT ype > 

</xs:element> 

<xs:complexType name="espduType "> 

<xs:sequence> 

<xs:element name = "header" type="headerType "/> 

<xs:element name = "entityID" type = "entityIDType "/> 

<xs:element name = "forcelD " type = "xs:byte "/> 

<xs:element name = "articulationNumber" type="xs:byte "/> 

<xs:element name = "entityType " type = "entityTypeType "/> 

<xs:element name = "alternativeEntityType " type="entityTypeType "/> 
<xs:element name = "linearVelocity" type='Yector3Eloat"/> 

<xs:element name = "location" type="locationType "/> 

<xs:element name = "orientation" type="orientationType "/> 

<xs:element name = "appearence " type="xs:int"/> 

<xs:element name = "deadReckoning" type = "deadReckoningType "/> 

<xs:element name = "entityMarking" type="entityMarkingType "/> 

<xs:element name = "capabilities" type="capabilitiesType "/> 

<xs:element name = "articulationParameters " type="articulationParameterType "/> 
</xs:sequence> 

</xs:complexType> 

<xs:complexType name="collisionpduType "> 

<xs:sequence> 

<xs:element name == "header" type=="headerType "/> 

<xs:element name=:"issuingEntityID" type = "entityIDType "/> 

<xs:element name = "collidingEntitylD " type = "entityIDType "/> 

<xs:element name = "eventID " type="eventIDType "/> 

<xs:element name = "collisionType " type = "xs:byte "/> 

<xs:element name = "padding" type="xs:byte"/> 

<xs:element name = "velocity " type='Yector3Float"/> 

<xs:element name=="mass" type=="xs:float"/> 

<xs:element name = "location" type='Yector3Float"/> 

</xs: sequence > 

</xs:complexType > 

<xs:complexType name=:"firepduType "> 
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<xs:sequence> 

<xs:element name = "header" type="headerType "/> 

<xs:element name = "firingEntityID" type = "entityIDType "/> 
<xs:element name = "targetEntityID" type = "entityIDType "/> 
<xs:element name=:"munitionID" type = "entityIDType "/> 
<xs:element name = "eventID " type="eventIDType "/> 

<xs:element name = "fireMissionIndex" type="xs:int"/> 

<xs:element name = "locationinWorld " type = "locationType "/> 
<xs:element name = "burstDescriptor" type = "burstDescriptorType "/> 
<xs:element name = "velocity " type='Yector3Eloat"/> 

<xs:element name== "range " type="xs:float"/> 

</xs:sequence> 

</xs:complexType> 

<xs:complexType name=:"detonationpduType "> 

<xs:sequence> 

<xs:element name = "header" type="headerType "/> 

<xs:element name = "firingEntitylD " type = "entityIDType "/> 

<xs Element name = "targetEntitylD " type = "entityIDType "/> 
<xs:element name = "munitionID " type = "entityIDType "/> 
<xs:element name = "eventID " type="eventIDType "/> 

<xs:element name = "velocity " type='Yector3Eloat"/> 

<xs:element name = "locationInWorld " type = "locationType "/> 
<xs:element name = "burstDescriptor" type = "burstDescriptorType "/> 
<xs:element name = "locationInEntity" type = 'Yector3Eloat"/> 
<xs:element name = "detonationResult" type="xs:byte "/> 

<xs:element name = "articulationNumber" type="xs:byte "/> 
<xs:element name = "padding" type="xs:short"/> 

</xs:sequence> 

</xs:complexType> 

<xs:complexType name="headerType "> 

<xs:sequence> 

<xs:element name=="protocolVersion" type = "xs:byte "/> 

<xs:element name = "exerciselD " type="xs:byte"/> 

<xs: element name = "pduType " type="xs:byte "/> 

<xs:element name = "protocolEamily" type = "xs:byte "/> 

<xs:element name = "timeStamp" type="xs:int"/> 

<xs:element name = "length " type = "xs:short "/> 

<xs:element name == "padding" type="xs:short"/> 

</xs:sequence> 

</xs :complexType > 

<xs:complexType name = "entityIDType "> 

<xs:sequence> 

<xs:element name = "site " type = "xs:short "/> 

<xs:element name = "application" type="xs:short"/> 

<xs:element name = "entity" type ="xs: short "/> 

</xs:sequence> 

</xs:complexType > 
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<xs:complexType name = "entityTypeType "> 

<xs:sequence> 

<xs:element name = "kind" type = "xs:byte "/> 

<xs:element name = "domain" type=="xs:byte "/> 

<xs:element name == "country" type ="xs: short "/> 

<xs:element name = "category" type="xs:byte "/> 

<xs:element name = "subcategory" type="xs:byte "/> 

<xs:element name = "specific " type = "xs:byte "/> 

<xs:element name = "extra" type = "xs:byte "/> 

</xs: sequence > 

</xs:complexType> 

<xs:complexType name="locationType "> 

<xs:attribute name="x" type="xs:double "/> 

<xs:attribute name="y" type="xs:double "/> 

<xs:attribute name="z" type = "xs:double "/> 

</xs:complexType > 

<xs:complexType name='Yector3Float"> 

<xs:attribute name="x" type="xs:float"/> 

<xs:attribute name="y" type="xs:float"/> 

<xs:attribute name="z" type = "xs:float"/> 

</xs:complexType > 

<xs:complexType name=="orientationType "> 

<xs:attribute name="psi" type="xs:float"/> 

<xs:attribute name="theta" type = "xs:float"/> 

<xs:attribute name="phi" type="xs:float"/> 

</xs:complexType> 

<xs:complexType name="deadReckoningType "> 

<xs:sequence> 

<xs:element name = "algorithm" type = "xs:byte "/> 

<xs:element name = "otherParameters " type = "otherParametersType "/> 
<xs:element name = "linearAcceleration " type='Yector3Float"/> 
<xs:element name=="linearAngularVelocity" type=="Vector3Float"/> 
</xs: sequence > 

</xs:complexType > 

<xs:complexType name = "otherParametersType "> 

<xs:attribute name="opl " type = "xs:byte "/> 

<xs:attribute name="op2" type = "xs:byte "/> 

<xs:attribute name="op3" type = "xs:byte "/> 

<xs:attribute name="op4" type = "xs:byte "/> 

<xs:attribute name="op5" type = "xs:byte "/> 

<xs:attribute name="op6" type = "xs:byte "/> 

<xs: attribute name="op7" type = "xs:byte "/> 

<xs:attribute name="op8" type = "xs:byte "/> 

<xs:attribute name="op9" type = "xs:byte "/> 

<xs:attribute name="oplO" type="xs:byte "/> 

<xs:attribute name="opll" type=:"xs:byte "/> 

<xs:attribute name="opl2" type="xs:byte "/> 


111 


<xs:attribute name="opl3" type="xs:byte "/> 

<xs:attribute name="opl4" type="xs:byte "/> 

<xs:attribute name="opl5" type="xs:byte "/> 

</xs : complexT ype > 

<xs:complexType name = "entityMarkingType "> 

<xs:sequence> 

<xs:element name = "characterSet" type="xs:byte "/> 
<xs:element name = "unsignedints " type = "unsignedIntsType "/> 
</xs: sequence > 

</xs:complexType > 

<xs:complexType name="unsignedIntsType "> 

<xs:attribute name="opl " type = "xs:byte "/> 

<xs: attribute name="op2" type = "xs:byte "/> 

<xs:attribute name="op3" type = "xs:byte "/> 

<xs:attribute name="op4" type = "xs:byte "/> 

<xs:attribute name="op5" type = "xs:byte "/> 

<xs:attribute name="op6" type = "xs:byte"/> 

<xs:attribute name="op7" type=:"xs:byte "/> 

<xs:attribute name="op8" type = "xs:byte "/> 

<xs:attribute name="op9" type = "xs:byte "/> 

<xs:attribute name="oplO" type="xs:byte "/> 

<xs:attribute name="opH" type="xs:byte "/> 

</xs:complexType > 

<xs:complexType name="capabilitiesType "> 

<xs:attribute name="opl" type = "xs:boolean"/> 

<xs:attribute name="op2" type = "xs:boolean"/> 

<xs:attribute name="op3" type = "xs:boolean"/> 

<xs:attribute name="op4" type = "xs:boolean"/> 

<xs:attribute name="op5" type = "xs:boolean"/> 

<xs:attribute name="op6" type = "xs:boolean"/> 

<xs:attribute name="op7" type = "xs:boolean'7> 

<xs:attribute name="op8" type = "xs:boolean"/> 

<xs:attribute name="op9" type = "xs:boolean"/> 

<xs:attribute name="oplO" type="xs:boolean'7> 

<xs:attribute name="opH" type="xs:boolean'7> 

<xs:attribute name="opl2" type="xs:boolean'7> 

<xs:attribute name="opl3" type="xs:boolean'7> 

<xs:attribute name="opl4" type="xs:boolean'7> 

<xs:attribute name="opl5" type="xs:boolean'7> 

<xs:attribute name="opl6" type="xs:boolean'7> 

<xs:attribute name="opl7" type="xs:boolean'7> 

<xs:attribute name="opl8" type="xs:boolean'7> 

<xs:attribute name="opl9" type="xs:boolean'7> 

<xs:attribute name="op20" type="xs:boolean'7> 

<xs:attribute name="op21" type="xs:boolean'7> 

<xs:attribute name="op22" type=="xs:boolean'7> 

<xs:attribute name="op23" type="xs:boolean'7> 
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<xs:attribute name="op24" type="xs:boolean"/> 
<xs:attribute name="op25" type="xs:boolean"/> 
<xs:attribute name="op26" type="xs:boolean"/> 
<xs:attribute name="op27" type="xs:boolean"/> 
<xs:attribute name="op28" type="xs:boolean"/> 
<xs:attribute name="op29" type="xs:boolean"/> 
<xs:attribute name="op30" type="xs:boolean"/> 
<xs:attribute name="op31" type="xs:boolean"/> 
<xs:attribute name="op32" type="xs:boolean"/> 
</xs:complexType > 

<xs:complexType name="eventIDType "> 

<xs:sequence> 

<xs: element name = "site " type = "xs: short "/> 

<xs:element name = "application" type="xs:short"/> 
<xs:element name = "eventNumber" type = "xs:short"/> 
</xs: sequence > 

</xs:complexType > 

<xs:complexType name="burstDescriptorType "> 
<xs:sequence> 

<xs:element name = "munition " type = "xs:long"/> 
<xs:element name = "warhead" type ="xs: short "/> 
<xs:element name = "fuze" type="xs:short"/> 

<xs: element name = "quantity " type ="xs: short "/> 
<xs:element name = "rate" type ="xs: short "/> 
</xs:sequence> 

</xs:complexType> 

<xs:complexType name="articulationParameterType "> 
<xs:sequence> 

<xs:element name = "typeDesignator " type="xs:byte "/> 
<xs:element name = "changeIndicator" type="xs:byte "/> 
<xs: element name = "id" type ="xs: short "/> 

<xs:element name=:"parameterType " type="xs:integer"/> 
<xs:element name = "parameterValue " type="xs:long"/> 
</xs: sequence > 

</xs:complexType> 

</xs:schema> 
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APPENDIX B. ENTITY STATE PDU EXAMPLE 


<?xml version="1.0" encoding="UTF-8"?> 

<espdu xmlns:xsi= "http://www.w3.org/2001/XMLSchema-instance" 
xsi:noNamespaceSchemaLocation="C:\XFSP\source\or^npsnet\xfsp\schemas\espdu.xsd 
"> 

<headei> 

<protocolV ersion> 1 </protocolV ersion> 

<exerciseID>2</exerciseID> 

<pduType>3</pduType> 

<protocolF amily >4</protocolF amily > 

<timeStamp> 1 000</timeStamp> 

<length>400</length> 

<padding>300</padding> 

</header> 

<entityID> 

<site>50</site> 

<application>60</application> 

<entity>7 0</entity> 

</entityID> 

<forceID> 1 9</forceID> 

<articulationN umber> 1 0</articulationN umber> 

<entityType> 

<kmd>l</kind> 

<domain> 1 </domain> 

<country>99</country> 

<category> 10</category> 

<subcategory>3</subcategory> 

<specific>5 </ specifio 
<extra>7 </extr a> 

</entityType> 

<altemativeEntityType> 

<kmd>l</kind> 

<domain>2</domain> 

<country>89</country> 

<category>2</category> 

<subcategory>5</subcategory> 

<specific>7 <J specifio 
<extra>5 </e xtra> 

</altemativeEntityType> 

<linearVelocityx= "12.90" y="1.6" ^"0.0"/> 

<locationx= "233.56" y="5.7" ^"1.8"/> 

<orientationphi= "0.6 " theta= "0.5 " psi= '0.0 "/> 

<appearence> 1 2345</appearence> 

<deadReckoning> 

<algorithm>4</algorithm> 
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<otherParameters op 1 =" 1 " op 1 0= " 10 " op 11 =" 11 " op 1 2= " 12 " op 1 3= "13 ” 
op 14= "14 " op 1 5= " 15 " op2= "2 " op3= ”3 " op4 = "4 " op5= ”5 " op6= "6 ” op7= '7 " op8= ”8 " 
op9='9"/> 

<linearAccelerationx="1.0" y="1.0" z="1.0"/> 

<linearAngularVelocity x="2.0" y="2.0" ^"2.0"/> 

</deadReckoning> 

<entityMarking> 

<characterSet>23</characterSet> 

<unsignedlnts opl="l " op2="2" op3="3" opl 1="1 1 " opl0="10" op4="4" op5="5 " 
op6= "6 " op7= '7 " op8= "8 " op9= "9 7> 

</entityMarking> 

<capabilities opl="true" opl0="true" opl 1= "false" op 12= "false" opl3="true" 
op 14= "false "op 15= "false" opl6= "false" op 17= "false" op 18= "false" opl9= "false" 
op2= "false" op20= "false" op21="false" op22= "false" op23="true " op24= "false" 
op25= "false "op26= "false" op27= "false" op28= "false " op29= "false" op3= "false" 
op30= "false "op31= "false" op32="false" op4="true" op5="true" op6="true" op7="false" 
op8= "false "op9= "false "/> 

<articulationParameters> 

<typeDesignatoi> 1 </typeDesignator> 

<changelndicator>2</changeIndicator> 

<id>5</id> 

<parameterType> 1 0</parameterType> 

<parameterV alue >7</parameterV alue> 

</articulationParameters > 

</espdii> 
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APPENDIX C. DETONATION PDU EXAMPLE 


<?xml version="1.0" encoding="UTF-8"?> 

<detonationpdu xmlns: xsi= ' 'http ://www. w3. org/2001/XMLSchema - instance " 
xsi:noNamespaceSchemaLocation= "C:\XFSP\source\org\npsnet\xfsp\schemas\detonation 
pdu.xsd"> 

<headei> 

<protocolV ersion>9</protocolV ersion> 

<exerciseID>9</exerciseID> 

<pduType>9</pduType> 

<protocolF amily >9</protocolF amily > 

<timeStamp> 1234567 8</timeStamp> 

<length>234</lengtli> 

<padding>3 3</padd ing> 

</header> 

<firingEntityID> 

<site>l<^ite> 

<application> l</application> 

<entity>99</entity> 

</firingEntityID> 

<targetEntityID > 

<site>l</site> 

<application> l</application> 

<entity>89</entit5C> 

</targetEntityID> 

<munitionID> 

<site>l</site> 

<application>2</application> 

<entity>3</entity> 

</munitionID> 

<eventID> 

<site>l</site> 

<application> l</application> 

<eventNumber>99</eventNumbei> 

</eventID> 

<velocityx="10.3" y=''44.2" ^"67.77> 

<locationInWorld x=''22.1" y="33.5" ^"12.9"/> 

<burstDescriptoi> 

<munition>2222222</munition> 

<warhead>l 1 l</warhead> 

<fuze>3 3 3</fuze> 

<quantity>444</quantity> 

<rate>5 55 </r ate> 

</burstDescriptor> 

<locationInEntity x= "123.456" y= "456.789" ^"980.123 "/> 

<detonationResult> 1 0</detonationResult> 
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<articulationNumber>0</articulationNumber> 
<padding>l 1 l</padding> 

</detonationpdu> 
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APPENDIX D. FIRE PDU EXAMPLE 


<?xml version="1.0" encoding="UTF-8"?> 

<firepdu xmlns:xsi= "http://www.w3.org/2001/XMLSchema-instance" 
xsi:noNamespaceSchemaLocation="C:\XFSP\source\or^npsnet\xfsp\schemas\firepdu.xsd"> 
<header> 

<protocolVersion>l</protocolVersion> 

<exerciseID>2</exerciseID> 

<pduType >3</pduType > 

<protocolFamily >4</protocolFamily > 

<timeStamp>5 5 5</timeStamp> 

<length>6</length> 

<padding>7 7 </padding > 

</header> 

<firingEntityID> 

<site>l</site> 

<application> 1 </application> 

<entity> 1 0</entity > 

</firingEntityID> 

<targetEntity ID > 

<site>l</site> 

<application> 1 </application> 

<entity>l l</entity> 

</targetEntityID> 

<munitionID> 

<site>l</site> 

<application> 1 </application> 

<entity> 1 0</entity > 

</munitionID> 

<eventID> 

<site>l</site> 

<application> 1 </application> 

<eventNumber>22</eventNumber> 

</eventID> 

<fireMissionIndex> 123567 </fireMissionIndex> 

<locationInWorld x= "464646.899" y="4646.28" z="19997.567"/> 

<burstDescriptor > 

<munition>47 7478 84</munition > 

<w arhe ad> 345 </warhe ad> 

<fuze >1 25</fuze > 

<quantity>l 00</quantity> 

<rate>10</rate> 

</burstDescriptor > 

<velocity x="10" y="10" z="10"/> 

<range> 19929. 991</range> 

</firepdu> 
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APPENDIX E. COLLISION PDU EXAMPLE 


<?xml version="1.0" encoding="UTF-8"?> 

<collisionpdu xmlns:xsf 'http://www.w3.org/2001/XMLSchema-instance" 
xsi:noNamespaceSc hemaLocation= "C :\XFSP\source\or^npsnet\xfsp\schemas\collisionp 
du.xsd"> 

<headei> 

<protocolV ersion> 1 </protocolV ersion> 

<exerciseID>2</exerciseID> 

<pduType>3</pduType> 

<protocolF amily >4</protocolF amily > 

<timeStamp>5 55 5</timeStamp > 

<length>34</length> 

<padding>444</padding> 

</header> 

<issuingEntityID> 

<site>10<^ite> 

<application>20</application> 

<entity>30</entity> 

</issuingEntityID> 

<collidingEntityID> 

<site>40</site> 

<application>50</application> 

<entity> 60 </entit 5 C> 

</collidmgEntityID> 

<eventID> 

<site>l</site> 

<application> l</application> 

<eventN umber> 101 </e ventNumber> 

</eventID> 

<collisionType>110</collisionType> 

<padding>33</padding> 

<velocityx="2.0" y="2.9" ^"3.0"/> 

<mass>34. 67 </mass> 

<locationx="101.01" y= "44.67" ^"12.10"/> 

</collisionpdu> 
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APPENDIX F. HIERARCHY OF ALL PACKAGES 


Package Hierarchies: 

org.npsnet.xfsp , 

org.npsnet.xfsp -datatypes , 

org.npsnet.xfsp.pduserver , 

org.npsnet.xfsp.swing , 

org. npsnet.xfsp.tests 

Class Hierarchy: 

o class org.npsnet.xfsp. BinaryReader 
o class org.npsnet■ xfsp. BinaryReaderX3D 
o class org.npsnet.xfsp.datatvpes. ComplexType (implements 
org.npsnet.xfsp.datatypes. Type) 
o class org.npsnet.xfsp.pduseryer. Help 
o class org.npsnet.xfsp.swing. LoaderDemo 
o class org.npsnet.xfsp.pduseryer. PDUServerWithGUI 
o class org.npsnet.xfsp.tests. ReceiverSimulation 
o class org.npsnet.xfsp.tests. SenderSimulation 
o class org.npsnet.xfsp.tests. Compressor 
o class org .npsnet ■ xfsp. DocumentProcessor 
o class org .npsnet ■ xfsp. DocumentProcessorX3D 
o class org.npsnet.xfsp. DOMManipulator 
o class org.npsnet.xfsp. DOMManipulatorX3D 
o class jayax.swing.filechooser.FilcFilter 

o class org.npsnet.xfsp.pduseryer. PDUServerWithGUI.PDUFileFilter 
o class org.npsnet.xfsp.pduseryer. PDUServerWithGUI.XSDFileFilter 
o class org.npsnet.xfsp.tests. ReceiverSimulation.SchemaFileFilter 
o class org.npsnet.xfsp.tests. SenderSimulation.XMLFileFilter 
o class org.npsnet.xfsp.datatypes. MFBool (implements 
org.npsnet.xfsp.datatypes. SimpleType) 
o class org.npsnet.xfsp.datatypes. MFColor (implements 
org.npsnet.xfsp.datatypes. SimpleType) 
o class org.npsnet.xfsp.datatypes. MFDouhle (implements 
org.npsnet.xfsp.datatypes. SimpleType) 
o class org.npsnet.xfsp.datatypes.MFFloat (implements 
org.npsnet.xfsp.datatypes. SimpleType) 
o class org.npsnet.xfsp.datatypes. MFImage (implements 
org.npsnet.xfsp.datatypes. SimplcType) 
o class org.npsnet.xfsp.datatypes. MFInt32 (implements 
org.npsnet.xfsp.datatypes. SimplcType) 
o class org.npsnet.xfsp.datatypes. MFRotation (implements 
org.npsnet.xfsp.datatypes. SimplcType) 
o class org.npsnet.xfsp.datatypes. MFString (implements 
org.npsnet.xfsp.datatypes. SimplcType) 
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o class org.npsnet.xfsp.datatypes.MFTime (implements 
org.npsnet.xfsp.datatypes.SimpleType) 
o class org.npsnet.xfsp.datatvpes. MFVec2d (implements 
org.npsnet.xfsp.datatypes. SimpleType) 
o class org.npsnet.xfsp.datatypes. MFVec2f (implements 
org.npsnet.xfsp.datatypes. SimpleType) 
o class org.npsnet.xfsp.datatypes. MFVec3d (implements 
org.npsnet.xfsp.datatypes. SimpleType) 
o class org.npsnet.xfsp.datatypes. MFVec3f (implements 
org.npsnet.xfsp.datatypes. SimpleType) 

o class org.npsnet.xfsp.pduseryer. MyTimer (implements jaya.lang.Runnable) 
o class org.npsnet.xfsp.pduserver. NetworkAnalyzerReceiver 
o class org.npsnet.xfsp.pduseryer. NetworkAnalyzerSender 
o class org.npsnet.xfsp.pduseryer. Packet 
o class org.npsnet.xfsp.pduseryer. PDUCapturer (implements 
jaya.lang.Runnable) 

o class org.npsnet.xfsp.pduseryer. PDU^erver 
o class org.npsnet.xfsp.pduserver. PDUSeryerWithGUI.PDUSender 
(implements jaya.lang.Runnable) 
o class org.npsnet.xfsp.datatypes. SFBool (implements 
org.npsnet.xfsp.datatypes. SimpleType) 
o class org.npsnet.xfsp.datatypes. SFColor (implements 
org. npsnet. xfsp. dat aty p es. SimpleType ) 
o class org.npsnet.xfsp.datatypes. SFDouble (implements 
org.npsnet.xfsp.datatypes. SimpleType) 
o class org.npsnet.xfsp.datatypes. SFFloat (implements 
org.npsnet.xfsp.datatypes. SimpleType) 
o class org.npsnet.xfsp.datatypes. SFImage (implements 
org.npsnet.xfsp.datatypes. SimpleType) 
o class org.npsnet.xfsp.datatypes. SFInt32 (implements 
org.npsnet.xfsp.datatypes. SimpleType) 
o class org.npsnet.xfsp.datatypes. SFRotation (implements 
org.npsnet.xfsp.datatypes. SimpleType) 
o class org.npsnet.xfsp.datatypes. SFString (implements 
org.npsnet.xfsp.datatypes. SimpleType) 
o class org.npsnet.xfsp.datatypes. SFTime (implements 
org.npsnet.xfsp.datatypes. SimpleType) 
o class org.npsnet.xfsp.datatypes. SFVec2d (implements 
org.npsnet.xfsp.datatypes. SimpleType) 
o class org.npsnet.xfsp.datatypes. SFVec2f (implements 
org.npsnet.xfsp.datatypes. SimpleType) 
o class org.npsnet.xfsp.datatypes. SFVec3d (implements 
org.npsnet.xfsp.datatypes. SimpleType) 
o class org.npsnet.xfsp.datatypes. SFVec3f (implements 
org.npsnet.xfsp.datatypes. SimpleType) 
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o class org.npsnet.xfsp.datatypes. SimpleTypeExtension (implements 
org.npsnet.xfsp.datatypes. SimpleTypeWithName) 
o class org.npsnet.xfsp. Table Attribute 
o class org.npsnet■ xfsp. TableAttributeX3D 
o class org.npsnet.xfsp. TableElement 
o class org.npsnet.xfsp. TableElementX3D 
o class org.npsnet.xfsp. TableManager 
o class org.npsnet.xfsp. TableManagerX3D 
o class org.npsnet.xfsp.datatypes. TypeFactory 
o class org.npsnet.xfsp.swing. XMLSwingTree 
o class org.npsnet.xfsp.datatypes. XSDBoolean (implements 
org.npsnet.xfsp.datatypes. SimpleType) 
o class org.npsnet.xfsp.datatypes. XSDByte (implements 
org.npsnet.xfsp.datatypes. SimpleType) 
o class org.npsnet.xfsp.datatypes. XSDComment (implements 
org.npsnet.xfsp.datatypes. SimpleType) 
o class org.npsnet.xfsp.datatypes. XSDDouble (implements 
org.npsnet.xfsp.datatypes. SimpleType) 
o class org.npsnet.xfsp.datatypes. XSDFloat (implements 
org.npsnet.xfsp.datatypes. SimpleType) 
o class org.npsnet.xfsp.datatypes. XSDInteger (implements 
org.npsnet.xfsp.datatypes. SimpleType) 
o class org.npsnet.xfsp.datatypes. XSDLong (implements 
org.npsnet.xfsp.datatypes. SimpleType) 
o class org.npsnet.xfsp.datatypes. XSDPrimitiyeArray (implements 
org.npsnet.xfsp.datatypes. SimpleTypeWithName) 
o class org.npsnet.xfsp.datatypes. XSDShort (implements 
org.npsnet.xfsp.datatypes. SimpleType) 
o class org.npsnet.xfsp.datatypes. XSDString (implements 
org.npsnet.xfsp.datatypes. SimpleType) 
o class org.npsnet.xfsp.datatypes. XSDUnsignedByte (implements 
org.npsnet.xfsp.datatypes. SimpleType) 
o class org.npsnet.xfsp.datatypes. XSDUnsignedInt (implements 
org.npsnet.xfsp.datatypes. SimpleType) 
o class org.npsnet.xfsp.datatypes. XSDUnsignedShort (implements 
org.npsnet.xfsp.datatypes. SimpleType) 
o interface org.npsnet.xfsp.datatypes. SimpleType 

o interface org.npsnet.xfsp.datatypes. SimpleTypeWithName 

Interface Hierarchy: 


o interface orgnpsnet.xfsp.datatypes. Type 

o interface org.npsnet.xfsp.datatypes. SimpleType 

o interface org.npsnet.xfsp.datatypes. SimpleTypeWithName 
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